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

["Price, Richard" <richard.price at roke.co.uk>]

> Surtees, Abigail <abigail.surtees@roke.co.uk> 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..

Even later still...

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

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

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

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.

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

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

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

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.

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

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

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

Look forward to hearing about them...

Regards,

Richard

> --Pekka
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc