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

From: Pekka Pessi <[email-masked]>
Date: Tue, 17 Feb 2004 21:34:00 +0200

Surtees, Abigail <[email-masked]> writes:
>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.) 

Even later..

...
>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?

I gather that the risk is the DoS attack by multiple concurrent
UDVMs? Does not sound very grave; UDVM looks like a (small) piece
of memory.

>Interpretation 2:

...
>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?  

I'd say so.

>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?

I initially assumed interpretation 2; then when I started checking
for the 64 kB limit (it really makes your life complicated ;), I
started using interpretation 1.

>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.

It is also possible to send a large SIP message using multiple
SigComp messages. Of course, this would mean that the SigComp
application (SIP stack) must accept/reject the SigComp message
before entire SIP message has been decompressed. 

OK, this violates assumptions behind the SigComp security model,
but, SIP cannot provide any kind of upper layer security for
SigComp unless *extremely* costly and/or underspecified S/MIME
tunneling is used. (There has been things like
draft-undery-sip-auth-01.txt under works, but they have expired
long time ago.) SigComp security model simply does not work with
current SIP. So, who cares about yet another invalidated
assumption as long as you have a reasonable underlying security
(IPSec, TLS)?

(Of course, there are other things in SigComp that does not work
with SIP, like the compression association and compartments, but I
rant about them some other time.)

--Pekka

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

---

From: [email-masked]
Date: Thu, 19 Feb 2004 19:22:56 -0500

Hi,

Looking back in the mirror, the reasons why RFC 3320 became as it is 
today were:
- we assumed no security below sigcomp
- NAT prevented a flow-based architecture; so came the state model.

Now, looking at SigComp over TCP over secure channel (as we are
discussing now), I feel we are really dealing with a special 
sub-case than the general one we assumed above. So special that 
I'm wondering if it makes sense to define SigComp version 0x02 
for this case:

- it can utilize the security below sigcomp and the reliability 
provided by TCP.

- it can include support for multiplexing SigComp and non-SigComp 
messages (people seem to agree at least it is good to have).

- based on Version 0x01, with minimal changes.

Best of all, the new version number solves the negotiation problem
for "continuous mode" and multiplexing.

Any comments?

BR,
Zhigang

---

From: "Price, Richard" <[email-masked]>
Date: Mon, 23 Feb 2004 17:07:29 -0000

> >consensus, it should be put into the implementer's guide.) 

Even later still...

> UDVMs? Does not sound very grave; UDVM looks like a (small) piece

I think it should be an implementation choice whether to buffer the
SigComp message before decompressing, because the security implications
are minimal.

This is different from what we mean by "continuous mode". Continuous
mode is a special mode of operation for SigComp, which can only be
used given prior agreement by the two endpoints. Unlike for vanilla
SigComp, in continuous mode there is no 1-1 mapping between SigComp
messages and SIP messages. A single SigComp message might contain any
number of SIP messages (even fragments of SIP messages).

Continuous mode cannot use the decompressed SIP messages for
authentication, so it needs additional security to be provided by
the lower layer (e.g. TLS).

> >this attack, then isn't it safe to drop the message limit?  

Yes, with one small caveat (see below).

Continuous mode treats the uncompressed data as a stream, without
caring about the boundaries between SIP messages. So it's ok for
the decompressed data to contain a single, huge SIP message of
more than 64k.

The caveat is that it's still important for each decompressed
*SigComp* message to contain no more than 64k of data. This is
a vital mechanism for protecting the UDVM against broken SigComp
messages which cause the UDVM to output data continually - we can't
rely on the lower-layer security to protect against broken
compressors ;-)

However, as continuous mode lets us break a single SIP message up
into more than one SigComp message, the 64k limit does not prevent
us from compressing really big SIP messages. They just need to be
split up into multiple SigComp messages first.

> started using interpretation 1.

Interpretation 2 is what we meant by "continuous mode" when we
were writing the RFC.

> before entire SIP message has been decompressed. 

Yes, which is why we can't do it with vanilla SigComp. However, it's
ok to do this with continuous mode, because there's extra security
at the lower layer.

> current SIP.

The SigComp security model doesn't assume that security is
provided by the upper layer. SigComp works equally well if
security is provided by the lower layer (in fact, it works
even better, because you can use continuous mode and compress
SIP messages more than 64k long).

> So, who cares about yet another invalidated assumption as long as
> you have a reasonable underlying security (IPSec, TLS)?

Well, this is what continuous mode is for ;-)

As stated in RFC 3320:

"continuous mode" invalidates some assumptions of the SigComp security
model and can only be used if the transport itself can provide the
required protection against denial of service attacks."

> rant about them some other time.)

Look forward to hearing about them...

Regards,

Richard

---

From: "Price, Richard" <[email-masked]>
Date: Mon, 23 Feb 2004 17:26:56 -0000

> - we assumed no security below sigcomp

More precisely, we assumed that security below SigComp was not
mandatory. SigComp Version 0x01 will certainly run in the presence
of lower-layer security, but not optimally.

> for "continuous mode" and multiplexing.

Another advantage, which follows from having continuous mode:

- Overcomes the 64k limit for application messages.

> Any comments?

This is a good suggestion for how to improve SigComp performance
if we have lower-layer security.

I'd be interested to know if this is just a nice-to-have, or is
there anything sufficiently broken about running SigComp Version
0x01 over lower-layer security to make a Version 0x02 a must?

Regards,

Richard

---

From: [email-masked]
Date: Mon, 23 Feb 2004 18:46:45 -0500

Hi Richard,

It looks now you have more time working/talking on SigComp. :-)

Please see my comments inline.

Zhigang

> of lower-layer security, but not optimally.

Agree. (I was too terse above.)
 
> - Overcomes the 64k limit for application messages.

Right.
 
> 0x01 over lower-layer security to make a Version 0x02 a must?

I wouldn't say SigComp Version 0x01 is broken. But a version 0x02
including continuous mode and multiplexing over TCP would be really
useful, for the advantages we have discussed (rid of 64KB limit,
using less TCP connections and IPsec SAs, etc.). That's particularly 
the case for 3GPP.

Also, I remember the goal of RFC 3320 was to be as generic as possible.
Time pressure to deliver SigComp was another factor. However, we didn't 
exclude the possibility of having a special variance for the case of 
security-at-lower-layer (I vaguely recall we had some discussions about
this during the development of RFC 3320).

---

From: [email-masked]
Date: Mon, 23 Feb 2004 19:26:49 -0500

Hi Pekka,

> long time ago.) 

Interesting. This raise a general question in my mind: let's forget 
about SigComp for a moment, does this mean people basically give up 
security at SIP layer, but instead rely on security at lower layer
(e.g. IPsec and TLS)?

> SigComp security model simply does not work with
> current SIP. 

Well, SigComp actually does not require security at application layer.
(see text below from "Security Considerations"). No security at 
application layer can be viewed as a special case.

   The overall security goal of the SigComp architecture is to not
   create risks that are in addition to those already present in the
   application protocols.

> So, who cares about yet another invalidated

I agree that having IPsec/TLS simplifies a lot of things.

BR,
Zhigang