Re: Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments)

2006-06-27 Thread Venkat Yekkirala
Venkat Yekkirala wrote: Keeping in mind (R1a), I wonder if it makes more sense for (OTBND1a) to take the label of the process/domain which sends the data to the socket? After all, the process/domain is the "origin" of the data. Right. This is what "ends up" happening in the non-privileged case

Re: Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments)

2006-06-27 Thread Venkat Yekkirala
Keeping in mind (R1a), I wonder if it makes more sense for (OTBND1a) to take the label of the process/domain which sends the data to the socket? After all, the process/domain is the "origin" of the data. Right. This is what "ends up" happening in the non-privileged case. In the privileged multi

Re: Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments)

2006-06-26 Thread Paul Moore
On Monday 26 June 2006 7:05 pm, Venkat Yekkirala wrote: > USER REQUIREMENTS: > > The broad user requirements for labeled networking would be that of > information labeling and flow control. Specifically, > > 1. Data labeling: > a. data must be labeled where it originates. > b. data must

Re: Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments)

2006-06-26 Thread James Morris
On Mon, 26 Jun 2006, Venkat Yekkirala wrote: > > What we need is a design rationale, some kind of detailed discussion of what > > the user requirements are and what the plan is for implementing features to > > meet these requirements. > > The following is not extensive in a formal/theoretical sen

Labeled Networking Requirements and Design (formerly RE: [PATCH 01/06] MLSXFRM: Granular IPSec associations for use in MLS environments)

2006-06-26 Thread Venkat Yekkirala
What we need is a design rationale, some kind of detailed discussion of what the user requirements are and what the plan is for implementing features to meet these requirements. The following is not extensive in a formal/theoretical sense, but hopefully addresses the need here. Needless to sa