Subject: RE: [rohc] Where is the pair operation figure in Sigcomp-05 ??

From: "Price, Richard" <[email-masked]>
Date: Tue, 5 Mar 2002 13:04:42 -0000

> Hi:
> 
> I am observing that when Sigcomp-04 has evolved to Sigcomp-05, the 
> figure 3 in SigComp-04 is missing in -05.
> 
> I didn't remember any discussion in the mailing list that concluded
> to remove this figure. Has there been such a discussion?

The figure 3 in SigComp-04 has been the source of a great deal of confusion.
The intention of the figure was to provide an overview of how the SigComp
initialisation might look - it did *not* mandate the exact message flow,
and indeed mandating a message flow within SigComp would be impossible for
security reasons. The exact message flow needs to change depending on the
particular signalling application (more on this below).

As part of the transition from -04 to -05, we deleted any text that offered
guidelines for how to use SigComp to compress a particular signalling
application. This includes text from the following sections:

Section 4.1
Section 5.1
Appendix A
Appendix B
Appendix C

The motivation for deleting the text is twofold - we cut down the size of
the draft, and we avoid the confusion whereby the guidelines are taken to
be a mandatory part of SigComp when in fact they are for information only.

Since an explanation of how to use SigComp would be very useful however,
Carsten proposes a "SigComp User Guide" draft containing the above sections
and any other helpful information.

> Further more, without this figure, I doubt SigComp can ever work.

The above statement highlights the misunderstanding that we are trying
to resolve. The figure is for information only, and removing it does not
make any technical difference to SigComp.

In fact, for the particular case of SIP the message flow of figure 3 is
wrong and cannot be used.

> At least I would like to understand how SigComp will work if there
> is not a process of exchaning information as described in the removed
> figure.

Certainly SigComp needs to be initialised with some kind of information
exchange, the result of which is that both endpoints have a copy of the
compression and decompression algorithms.

However ... the message flow given in figure 3 is only one example of
how this information exchange might take place. In fact, the exact
message flow changes depending on the particular signalling application.
The reason for this is that over an unreliable transport such as UDP, to
protect against DoS attacks it isn't possible to send standalone SigComp
messages. Therefore the initialisation phase of SigComp must be
piggybacked onto existing application messages.

This means that the actual SigComp message flow depends on the particular
signalling application. In the case of SIP for example, the registration
phase may only contain two messages (REGISTER and 200 OK), so the
initialisation needs to be piggybacked onto these two messages only.

One way to do this might be as follows:

|     SigComp Request/Announce + UDVM upload     | 
|----------------------------------------------->| (REGISTER)
|                                                | 
|                                                | 
|          Announcement + UDVM download          | 
|<-----------------------------------------------| (200 OK)
|                                                |    
|          Ready for compression                 |

A "SigComp User Guide" would be a good place to discuss this issue
further.

Regards,

Richard

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 05 Mar 2002 15:34:28 +0200

Hi Richard:

So I understand now that, at least, one of the possible ways that SigComp 
may use to work is the one depicted in Figure 3 (sigcomp-04), although
there may be other ways of operation.

If this is the case, I would like to understand how are those SigComp
Request, SigComp Capabilities announcement and UDVM upload messages 
distinguished from SigComp compressed messages. The SigComp message format
in section 4.2 of Sigcomp-05 does not include any means to identify the
message type. Or am I missing something?

> wrong and cannot be used.

I believe that figure 3 can be used for SIP and any other protocol. I would like
to understand what is wrong with the figure and why do you say that it does 
not work with SIP. In my understanding, the first application compressed 
message in figure 3 is the "Compressed messages" at the bottom of the figure.

You mention also the security of the SigComp negotiation. SIP recommends to 
authenticate the REGISTER message, and this is what we are doing in 3GPP.
The first SIP REGISTER message is authenticated. Although this topic has not
been discussed deeply, I believe some folks will prefer to postpone the 
start of Sigcomp until the user is authenticated. In the case of 3GPP,
the authentication procedure includes a dobule round trip (REGISTER, 401, 
REGISTER, 200). These messages will probably be sent uncompressed, and
afterwards, SigComp can be started and compressed message can be sent.

/Miguel

"Price, Richard" wrote:
>                                                   ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>                           Name: RMRL-Disclaimer.txt
>    RMRL-Disclaimer.txt    Type: Plain Text (text/plain)
>                       Encoding: 7bit

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

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

---

From: Lawrence Conroy <[email-masked]>
Date: Tue, 5 Mar 2002 14:23:00 +0000

At 3:34 pm +0200 5/3/02, Miguel A. Garcia wrote:
><snip>
>start of Sigcomp until the user is authenticated.
To which I reply:

Hi Miguel, folks,
That's not quite my understanding of CN1's output;
   I understood that other folks still wanted the bonus of compressed
REGISTER messages; i.e. none of the contribs. were completely accepted.

I understood that the reason that some folks did not want compression for
everything was a common (hey, it's 3GPP :) misunderstanding of the cost of
compression/decompression versus authentication/message integrity.

Thus maybe compression will be allowed in the first REG message pair, and
(more likely) the subsequent/successful REG message pair. It's also possible
that it won't be done at all for REG - basically, the horses are still running.

all the best,
    Lawrence
-- 
[email-masked]: +44 1794 833666::<my opinions>:

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 05 Mar 2002 16:35:41 +0200

Lawrence:

As I said, the discussion on whether to compress and then authenticate,
or authenticate and then compress, or all together in one shot, has not
been debated yet. 

I am just saying that I heard opinions in favor of authenticating and 
then compressing. That is what I said.

/Miguel