Re: [rohc] draft-ietf-rohc-sigcomp-04.txt

["Miguel A. Garcia" <[e-mail]>]

Hi Hans and the rest of the rochers:

I think Hans already agreed on some of the points, so I will comment only
on those that I think we didn't get an agreement yet. 

"Hans Hannu (EPL)" wrote:
> 
> Hi Miguel,
> 
> > 3) Section 3, SigComp architecture, 2nd paragraph:
> >
> >    "SigComp is typically offered to applications as a "shim" layer
> >    between the application and the transport. Note however that for
> >    certain applications the compressed SigComp message may be passed
> >    back to the application itself for additional processing before
> >    transmission. For example, the application may wish to apply
> >    encryption to the compressed message before handing it to the
> >    transport. "
> >
> >    I don't think this scenario is possible. To my understanding,
> >    there are two types of encryption: end-to-end and hop-by-hop.
> 
> This roles back to whether SigComp is applied IP end-to-end (Endpoint - first proxy ), or "SIP end-to-end" (SIP endpoint to SIP endpoint).
> 
> >    I would like to hear comments on the above statements. And
> >    certainly clarify what is the relationship between the application
> >    and SigComp.
> 
> I think this comes back to which scenario we want to solve. If it is the SIP end-to-end scenario with encryption, this may probably make SIP/SigComp require an assigned port number and SigComp would not be regarded as a shim layer to SIP, but the implementation would have to be totally integrated.

<Miguel> I think that still is not clear to me the relation or problems with
the encryption. Let's imagine the typical SIP trapezoid, that is, two endpoints
A and B communicating with two other proxies (P1, P2) in the middle. So the
chain is A - P1 - P2 - B

Lets assume that SigComp is running between A and P1.

The SIP layer in A builds a SIP message. As the end receiver is B, and A wants to send
some very secret information that only B is able to read, A decides to encrypt that 
information with some secret key so that the information is only decoded by B. Note 
that those SIP header field values that are sensitive to be used by proxies during
routing MUST not be encrypted, otherwise, P1 and P2 can't route the message. 

So A has a SIP message destined to B (through P1 and P2) where certain header field
values are encrypted. This message is passed to the local SigComp shim layer. Sigcomp
compresses the message. After that, there may be other encryption mechanism that run
between A and P1, such as TLS or some other encryption layer. SigComp passes the 
message to the "hop-by-hop encryption layer", whatever that is.

This what I was thinking all about. This mechanism allows end-to-end encryption of
certain values, and hop-by-hop encryption of the whole message. And it does not
require to return a compressed message back to the application (as I understood in
the original text).

I believe this covers all the requirements for encryption.

</Miguel>

> 
> >    Particularly it needs to be clarified which layer
> >    is responsible to forward the message: the SigComp layer or the
> >    application layer.
> 
> With my current understanding of our work and if it is as you say then I think it does not make sense to pass up a compressed message to the application to forward the SigComp message.

<Miguel> I agree. Imagine that the SIP layer receives a SIP compressed message. It will fail to
parse the message. That is for sure. There is nothing SIP can do with a compressed message.

</Miguel>

> 
> > 8) Section 4.2, first paragraph:
> >
> >    "The basic SigComp message consists of a block of UDVM
> > bytecode, the
> >    first n bytes of which are interpreted as a state identifier that
> >    accesses some previously stored state information. "
> >
> >    I think this is inherited from the UDVM draft and it is not valid
> >    anymore. The basic SigComp message will NOT consist only of UDVM
> >    bytecode. Whatever the basic SigComp message is made of, should be
> >    reflected in the paragraph.
> 
> There is a note in the draft about solving the identification of different types of messages by reserving state identifiers. However, I now think that this is not possible for the following reason:
> 
> * SigComp do not know the length of the state identifier prior to the capability announcement.
> - As SigComp does separate flows, SigComp needs to carry the hash length for each message.
> 
> I think this make it valid to introduce some bits to identify the particular message type. Thus, the basic SigComp message format would change to something like this:
> 
>      0   1   2   3   4   5   6   7
>    +---+---+---+---+---+---+---+---+
>    |  MT   |Reserv.|  hash length  |
>    +---+---+---+---+---+---+---+---+
>    |                               |
>    :   state_identifier (n-bytes)  :
>    |                               |
>    +---+---+---+---+---+---+---+---+
>    |                               |
>    :    Remaining UDVM bytecode    :
>    |                               |
>    +---+---+---+---+---+---+---+---+
> 
> The MT, Message Type, would indicate what type of message it is, e.g. SigComp request/announcement, "ordinary" SigComp compressed message.

<Miguel> I was thinking that you would need a Message Type as you were pointing
out. If we would agree on this, I would say that 2 bits seems to be a little
bit constraining... It allows for a maximum of 4 message types. That seems to 
be very limiting. Perhaps you need 3 bits as a minimum.
</Miguel>


> 
> > 12) Section 6.3., figure 5.
> >
> >     The figure refers to a Capability announcement "block".
> 
> Yes, we need to define the term "block". What do you think about the following:
> 
> "Capability announcement block"
> formatted capability announcement information
> 

<Miguel> My question is: do we need to introduce a new concept "block" in the
draft? If there is a need or it clarifies something to the reader, it is fine.
But it seems difficult to justify that you don't need the "block" concept until
section 6.3, but you needed afterwards.
</Miguel>

Regards,

    Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[e-mail]     Phone:  [phone]
mailto:[e-mail]        Mobile: [phone]

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