Subject: [rohc] Questions on sigcomp-05

From: Kevan Hobbis <[email-masked]>
Date: Thu, 14 Mar 2002 15:30:59 -0000

Colleagues

I have some questions on sigcomp-05 which may overlap a little with some of
the other discussions going on, but I believe the ongoing discussions are at
least a layer of detail lower than mine.

1. Section 4.3 talks about the endpoint identifiers and their need to be
unique. It also says that the format is unimportant. I understood from later
sections 

- see section 3.1 very last paragraph where is says 
"
In the interests of security, a new interface is required to the 
   signalling application in order to leverage the authentication 
   functions built into the application itself. When the application 
   receives a decompressed message it determines the identity of the 
   sending endpoint and supplies this information to the state handler"

and section 6.1 fourth para where it says
"Upon receiving a decompressed message, the application may supply the 
   state handler with the identity of the sending endpoint. "

so the receiver would need to know the endpoint name used by the transmitter
- which means it must be sent over the communications link. Therefore the
format will be important ? Or am I wrong about the need for the receiver to
know about the transmitter endpoint name ?

2.  Section 5.1 bullet 3 implies that I can have a pre-arranged algorithm
referred to using some presumably pre-arranged state identifier ? I believe
that the state identifiers are generated by the compressor ? Do I need to
define these pre-arranged identifiers somewhere so that no compressor ever
uses one by accident that I have assumed to be some pre-loaded well known
state ?

3. Section 6.1 third paragraph says that 
"State can only 
   be created when a complete message has been successfully 
   decompressed, and the state handler MUST NOT save state without 
   permission from the application. "

This needs to be modified to say something like "except in the case where a
pre-defined state has been agreed. " to be in line with section 5.1 ?

4. Section 6.1 talks about the items stored for state and says that
state_identifier is 16 bytes. I think from other parts of the document (e.g.
6.3.3) that state_identifier is between 1 and 16 bytes ? Is this correct ?

Thanks

Kevan Hobbis
Hutchison 3G UK

_______________________________________________________________

If this email isn't for you then we'd be grateful if you could let our
helpdesk know there's been a mistake by putting 'received in 
error' in the subject box and sending it to [email-masked]. 
If it isn't for you, we're sure you'll understand that you're not 
allowed to copy, disclose or distribute any of its contents.  
This email is private and confidential and may also be privileged,
so if you shouldn't have received it, we'd be grateful if you could delete it.
Thanks.
________________________________________________________________

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

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 14 Mar 2002 17:48:10 -0000

> know about the transmitter endpoint name ?

Hi,

The receiver always needs to know the transmitter endpoint name when validating
a new state creation request or a new announcement request. The reason for this
is to prevent DoS attacks on SigComp, in which a malicious sender creates false
state or announcement information at the receiver.

The endpoint identity is already sent over the link as part of the uncompressed
message, and it is extracted by the receiving application during the normal
authentication process. This means that both the sending and the receiving
application need to agree on a common format for the endpoint identity.

After the receiving application has discovered the endpoint identity of the
sender, it is passed back to SigComp so that state and announcement data can
be saved in the sender's name. However, from the perspective of SigComp the
exact format of the endpoint identity doesn't matter. The only requirement is
that each endpoint gets a unique identity (so that one endpoint can't steal
resources from a different endpoint). In fact, if a particular application
is communicating with 20 remote endpoints then labeling them Endpoint 1 to
Endpoint 20 would be good enough for SigComp.

> uses one by accident that I have assumed to be some pre-loaded well known

When new state is created on the fly, the state identifiers are always a
hash of the state information that will be saved. The minimum hash size must
be sufficient to prevent malicious users from guessing the state identifiers;
our current view is that at least 9 bytes will be needed to provide enough
security.

For pre-arranged algorithm it's a good idea to also identify the algorithm
using a 9-byte hash over the code. The probability of accidental hash
collision is negligible (1 in 2^72) so there is no need to reserve a list
of identifiers for well-known algorithms.

> 3. Section 6.1 third paragraph says that "State can only 

Yes, the above paragraph refers only to state created on the fly at the
decompressor. Pre-defined state is created separately as part of the
application-defined parameters (see the last paragraph of Section 3.2).

> 6.3.3) that state_identifier is between 1 and 16 bytes ? Is this correct ?

State identifiers are between 1 and 16 bytes long when they are transmitted
over the air, but for simplicity they are always stored by the state handler
as 16-byte values. The state handler simply pads any remaining bytes with
zeroes until the state identifier is 16 bytes long.

Regards,

Richard