Subject: RE: [rohc] SigComp assumptions about security

From: [email-masked]
Date: Thu, 14 Mar 2002 20:31:43 -0600

> > - Integrity protection is assumed. Section 10.1: "The SigComp
> > approach assumes that there is appropriate integrity protection
> > below and/or above the SigComp layer."
> 
> I think this is 10.2.

Oops.

> Anyway, this just means that sigcomp itself is not making any 
> contributions to integrity protection, the text then goes on how sigcomp 
> might compromise integrity protection below it (and why it doesn't).

OK. Should we then use the above statement instead of the existing one
(which is quite confusing, at least to me)?

> > - Do we assume application always has authentication? Many
> > of SigComp operations (e.g. state creation/deletion) will
> > be carried out by permission of the application. But what
> > if application has no ability to make the decision? Does
> > that mean SigComp is paralyzed?
> 
> If the app has no way to make the decision, you can't use state.

Fair enough. I guess you mean we cannot install/modify/delete states 
(and change application parameters for that matter). But we can still 
refer to well-know state established as a-priori (e.g. decompression 
code or a piece of static dictionary)? 

BR,
Zhigang

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

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Fri, 15 Mar 2002 09:56:00 +0100

> (which is quite confusing, at least to me)?

Yes, this is a welcome editorial comment.

> code or a piece of static dictionary)?

The problem is that you can't even use state announcements without some form
of application security.
Of course, in a closed environment, you can still use pre-agreed state.

Gruesse, Carsten