* Richard Brooks <[email protected]> [2012-08-01 13:36:07]:
* [Clemson/Brooks] Development of tools for analytical verification of protocols for deadlock, livelock, performance, and information leakage by leveraging AESOP primitives.
--> Still not sure about this one. Do we have any more detail on how this would actually work before committing to delivering this?
How does it sound to do planning here and implementation in the out years?
It's not about the timing; It's just that I don't currently see how aesop primitives make this task easier/possible (that probably says more about me than about the deliverable). Maybe leave aesop out of it, but keep the rest? That would give you the flexibility to investigate other options if needed.
* [Clemson/Brooks] Tools for identifying and mitigating denial of service incidents.
----> Denial of service and related events are basically accounting for 50% of yr3, 33% of yr 4 and 50% of yr 5 (with yr 4 and yr 5 being the same deliverable). Can we really justify so much effort to this one topic?
Is it an issue in similar storage systems? For example, do lustre/gpfs/... have anything in this area and if not, are they looking into adding this?
Given the intended deployment of the storage system, there might be other areas that could provide more benefit?
Do you have suggestions for anything you might find more useful?
That would be welcome. Coming up with 5 year plans with a one day turn around is challenging.
Ideas from you are very welcome at this point....
Unfortunately, no. :( The only thing I can come up with now is to investigate and implement the authorization for the other frontends we would support? (i.e. for posix for example), but not sure if this makes a good deliverable. (It is something we need though). Ideas/suggestions from other people? Dries
On 08/01/2012 02:01 PM, Dries Kimpe wrote:
----> Denial of service and related events are basically accounting
for 50% of yr3, 33% of yr 4 and 50% of yr 5 (with yr 4 and yr 5 being the same deliverable). Can we really justify so much effort to this one topic? Is it an issue in similar storage systems? For example, do lustre/gpfs/... have anything in this area and if not, are they looking into adding this? Given the intended deployment of the storage system, there might be other areas that could provide more benefit? Do you have suggestions for anything you might find more useful? That would be welcome. Coming up with 5 year plans with a one day turn around is challenging. Ideas from you are very welcome at this point.... Unfortunately, no.:(
The only thing I can come up with now is to investigate and implement the authorization for the other frontends we would support? (i.e. for posix for example), but not sure if this makes a good deliverable.
(It is something we need though).
Ideas/suggestions from other people?
Dries
I'm rather late commenting on this, and I'm no security expert, but from my perspective I agree with the notion of de-emphasizing the DOS stuff in favor of other topics. I've always had the impression that DOS problems seem more critical to storage systems (or other services) that are open to the Internet at large. For the type of storage system we are building, I would expect things like unauthorized data access, how to tie in with external auth mechanisms, and how to migrate data on and off of storage safely to be bigger concerns. Some level of DOS exploration is good though, especially if there is some potential (for example) for an application to use DOS as a tool towards gaining unauthorized access, though. I don't know if that's a plausible possibility or not. -Phil
On Aug 2, 2012, at 9:01 AM, Phil Carns wrote:
On 08/01/2012 02:01 PM, Dries Kimpe wrote:
----> Denial of service and related events are basically accounting
for 50% of yr3, 33% of yr 4 and 50% of yr 5 (with yr 4 and yr 5 being the same deliverable). Can we really justify so much effort to this one topic? Is it an issue in similar storage systems? For example, do lustre/gpfs/... have anything in this area and if not, are they looking into adding this? Given the intended deployment of the storage system, there might be other areas that could provide more benefit? Do you have suggestions for anything you might find more useful? That would be welcome. Coming up with 5 year plans with a one day turn around is challenging. Ideas from you are very welcome at this point.... Unfortunately, no.:( The only thing I can come up with now is to investigate and implement the authorization for the other frontends we would support? (i.e. for posix for example), but not sure if this makes a good deliverable.
(It is something we need though).
Ideas/suggestions from other people?
Dries
I'm rather late commenting on this, and I'm no security expert, but from my perspective I agree with the notion of de-emphasizing the DOS stuff in favor of other topics. I've always had the impression that DOS problems seem more critical to storage systems (or other services) that are open to the Internet at large. For the type of storage system we are building, I would expect things like unauthorized data access, how to tie in with external auth mechanisms, and how to migrate data on and off of storage safely to be bigger concerns.
Some level of DOS exploration is good though, especially if there is some potential (for example) for an application to use DOS as a tool towards gaining unauthorized access, though. I don't know if that's a plausible possibility or not.
Agreed. Were I reviewing this program I would ask for our thinking here; Why are we paying so much attention to this for a system that will run only on networks over which absolute, dictatorial, control exists. Our risk is the compromise of information by the insider. That, by far, is the number one, most, consequential event that I can imagine. From that, it seems reasonable to conclude that the end-point of an attack lies at the hosts in the network, that the infrastructure is unreasonably difficult to leverage for an attack. Are we paying enough attention to the hosts? Are we confident we know the vectors, there? Are we confident we can defend against those vectors? Were I a reviewer… --Lee
-Phil _______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
Am revising my inputs. The logic behind looking at denial of service was that denial of service can also be looked at as compromising quality of service. You look at the system and see if, and under which conditions, it is possible to construct workloads that severely impact performance. In some ways, it is another way of looking at a combination of dependability and scalability. Although it is phrased from an adversarial point of view, in implementation it does not have to be. If pathological uses of the system exists, it will eventually be found by accident (if not on purpose.) That said, I appreciate the comments and am redrafting my inputs. The comments you have would occur to others. I would appreciate, though, some feedback as to whether you find the idea of looking for situations that produce bad outcomes reasonable in this context, or not. On 08/02/2012 11:21 AM, Ward, Lee wrote:
On Aug 2, 2012, at 9:01 AM, Phil Carns wrote:
On 08/01/2012 02:01 PM, Dries Kimpe wrote:
----> Denial of service and related events are basically accounting
for 50% of yr3, 33% of yr 4 and 50% of yr 5 (with yr 4 and yr 5 being the same deliverable). Can we really justify so much effort to this one topic? Is it an issue in similar storage systems? For example, do lustre/gpfs/... have anything in this area and if not, are they looking into adding this? Given the intended deployment of the storage system, there might be other areas that could provide more benefit? Do you have suggestions for anything you might find more useful? That would be welcome. Coming up with 5 year plans with a one day turn around is challenging. Ideas from you are very welcome at this point.... Unfortunately, no.:( The only thing I can come up with now is to investigate and implement the authorization for the other frontends we would support? (i.e. for posix for example), but not sure if this makes a good deliverable.
(It is something we need though).
Ideas/suggestions from other people?
Dries
I'm rather late commenting on this, and I'm no security expert, but from my perspective I agree with the notion of de-emphasizing the DOS stuff in favor of other topics. I've always had the impression that DOS problems seem more critical to storage systems (or other services) that are open to the Internet at large. For the type of storage system we are building, I would expect things like unauthorized data access, how to tie in with external auth mechanisms, and how to migrate data on and off of storage safely to be bigger concerns.
Some level of DOS exploration is good though, especially if there is some potential (for example) for an application to use DOS as a tool towards gaining unauthorized access, though. I don't know if that's a plausible possibility or not.
Agreed. Were I reviewing this program I would ask for our thinking here; Why are we paying so much attention to this for a system that will run only on networks over which absolute, dictatorial, control exists.
Our risk is the compromise of information by the insider. That, by far, is the number one, most, consequential event that I can imagine. From that, it seems reasonable to conclude that the end-point of an attack lies at the hosts in the network, that the infrastructure is unreasonably difficult to leverage for an attack. Are we paying enough attention to the hosts? Are we confident we know the vectors, there? Are we confident we can defend against those vectors?
Were I a reviewer�
--Lee
-Phil _______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
-- =================== R. R. Brooks Associate Professor Holcombe Department of Electrical and Computer Engineering Clemson University 313-C Riggs Hall PO Box 340915 Clemson, SC 29634-0915 USA Tel. 864-656-0920 Fax. 864-656-5910 email: [email protected] web: http://www.clemson.edu/~rrb
On 08/02/2012 12:39 PM, Richard Brooks wrote:
Am revising my inputs.
The logic behind looking at denial of service was that denial of service can also be looked at as compromising quality of service.
You look at the system and see if, and under which conditions, it is possible to construct workloads that severely impact performance. In some ways, it is another way of looking at a combination of dependability and scalability. Although it is phrased from an adversarial point of view, in implementation it does not have to be. If pathological uses of the system exists, it will eventually be found by accident (if not on purpose.)
Maybe this can be thought of as a QOS problem? Even if the workload isn't malicious, it would be nice if one large application did not starve another application from making progress due to some bottleneck in the security infrastructure. QOS in general is a concern in storage systems, and it seems reasonable to think about it in the context of the security framework as well. -Phil
That said, I appreciate the comments and am redrafting my inputs. The comments you have would occur to others.
I would appreciate, though, some feedback as to whether you find the idea of looking for situations that produce bad outcomes reasonable in this context, or not.
On 08/02/2012 11:21 AM, Ward, Lee wrote:
On Aug 2, 2012, at 9:01 AM, Phil Carns wrote:
On 08/01/2012 02:01 PM, Dries Kimpe wrote:
----> Denial of service and related events are basically accounting
for 50% of yr3, 33% of yr 4 and 50% of yr 5 (with yr 4 and yr 5 being the same deliverable). Can we really justify so much effort to this one topic? Is it an issue in similar storage systems? For example, do lustre/gpfs/... have anything in this area and if not, are they looking into adding this? Given the intended deployment of the storage system, there might be other areas that could provide more benefit? Do you have suggestions for anything you might find more useful? That would be welcome. Coming up with 5 year plans with a one day turn around is challenging. Ideas from you are very welcome at this point.... Unfortunately, no.:( The only thing I can come up with now is to investigate and implement the authorization for the other frontends we would support? (i.e. for posix for example), but not sure if this makes a good deliverable.
(It is something we need though).
Ideas/suggestions from other people?
Dries
I'm rather late commenting on this, and I'm no security expert, but from my perspective I agree with the notion of de-emphasizing the DOS stuff in favor of other topics. I've always had the impression that DOS problems seem more critical to storage systems (or other services) that are open to the Internet at large. For the type of storage system we are building, I would expect things like unauthorized data access, how to tie in with external auth mechanisms, and how to migrate data on and off of storage safely to be bigger concerns.
Some level of DOS exploration is good though, especially if there is some potential (for example) for an application to use DOS as a tool towards gaining unauthorized access, though. I don't know if that's a plausible possibility or not. Agreed. Were I reviewing this program I would ask for our thinking here; Why are we paying so much attention to this for a system that will run only on networks over which absolute, dictatorial, control exists.
Our risk is the compromise of information by the insider. That, by far, is the number one, most, consequential event that I can imagine. From that, it seems reasonable to conclude that the end-point of an attack lies at the hosts in the network, that the infrastructure is unreasonably difficult to leverage for an attack. Are we paying enough attention to the hosts? Are we confident we know the vectors, there? Are we confident we can defend against those vectors?
Were I a reviewer�
--Lee
-Phil _______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
Exactly. Would a change of terms to "QoS degradation analysis" be on point and acceptable to reviewers? On 08/02/2012 01:04 PM, Phil Carns wrote:
On 08/02/2012 12:39 PM, Richard Brooks wrote:
Am revising my inputs.
The logic behind looking at denial of service was that denial of service can also be looked at as compromising quality of service.
You look at the system and see if, and under which conditions, it is possible to construct workloads that severely impact performance. In some ways, it is another way of looking at a combination of dependability and scalability. Although it is phrased from an adversarial point of view, in implementation it does not have to be. If pathological uses of the system exists, it will eventually be found by accident (if not on purpose.)
Maybe this can be thought of as a QOS problem? Even if the workload isn't malicious, it would be nice if one large application did not starve another application from making progress due to some bottleneck in the security infrastructure. QOS in general is a concern in storage systems, and it seems reasonable to think about it in the context of the security framework as well.
-Phil
That said, I appreciate the comments and am redrafting my inputs. The comments you have would occur to others.
I would appreciate, though, some feedback as to whether you find the idea of looking for situations that produce bad outcomes reasonable in this context, or not.
On 08/02/2012 11:21 AM, Ward, Lee wrote:
On Aug 2, 2012, at 9:01 AM, Phil Carns wrote:
On 08/01/2012 02:01 PM, Dries Kimpe wrote:
----> Denial of service and related events are basically accounting
for 50% of yr3, 33% of yr 4 and 50% of yr 5 (with yr 4 and yr 5 being the same deliverable). Can we really justify so much effort to this one topic? Is it an issue in similar storage systems? For example, do lustre/gpfs/... have anything in this area and if not, are they looking into adding this? Given the intended deployment of the storage system, there might be other areas that could provide more benefit? Do you have suggestions for anything you might find more useful? That would be welcome. Coming up with 5 year plans with a one day turn around is challenging. Ideas from you are very welcome at this point.... Unfortunately, no.:( The only thing I can come up with now is to investigate and implement the authorization for the other frontends we would support? (i.e. for posix for example), but not sure if this makes a good deliverable.
(It is something we need though).
Ideas/suggestions from other people?
Dries
I'm rather late commenting on this, and I'm no security expert, but from my perspective I agree with the notion of de-emphasizing the DOS stuff in favor of other topics. I've always had the impression that DOS problems seem more critical to storage systems (or other services) that are open to the Internet at large. For the type of storage system we are building, I would expect things like unauthorized data access, how to tie in with external auth mechanisms, and how to migrate data on and off of storage safely to be bigger concerns.
Some level of DOS exploration is good though, especially if there is some potential (for example) for an application to use DOS as a tool towards gaining unauthorized access, though. I don't know if that's a plausible possibility or not. Agreed. Were I reviewing this program I would ask for our thinking here; Why are we paying so much attention to this for a system that will run only on networks over which absolute, dictatorial, control exists.
Our risk is the compromise of information by the insider. That, by far, is the number one, most, consequential event that I can imagine. From that, it seems reasonable to conclude that the end-point of an attack lies at the hosts in the network, that the infrastructure is unreasonably difficult to leverage for an attack. Are we paying enough attention to the hosts? Are we confident we know the vectors, there? Are we confident we can defend against those vectors?
Were I a reviewer�
--Lee
-Phil _______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
-- =================== R. R. Brooks Associate Professor Holcombe Department of Electrical and Computer Engineering Clemson University 313-C Riggs Hall PO Box 340915 Clemson, SC 29634-0915 USA Tel. 864-656-0920 Fax. 864-656-5910 email: [email protected] web: http://www.clemson.edu/~rrb
On Aug 2, 2012, at 10:39 AM, Richard Brooks wrote:
Am revising my inputs.
The logic behind looking at denial of service was that denial of service can also be looked at as compromising quality of service.
You look at the system and see if, and under which conditions, it is possible to construct workloads that severely impact performance. In some ways, it is another way of looking at a combination of dependability and scalability. Although it is phrased from an adversarial point of view, in implementation it does not have to be. If pathological uses of the system exists, it will eventually be found by accident (if not on purpose.)
That said, I appreciate the comments and am redrafting my inputs. The comments you have would occur to others.
I would appreciate, though, some feedback as to whether you find the idea of looking for situations that produce bad outcomes reasonable in this context, or not.
I do find the idea of looking for such situations valuable. The context in which such situations might conceivably occur is related to the impact, and so the value of that exploration, though. A DOS attack on our file systems is a low-impact, transient, issue that is easily corrected because the network is managed dictatorially. An offending host or network can be trivially fenced from the infrastructure. A successful DOS attack originating from within an enterprise would be a direct result of naive network management. It would be the management policy requiring attention, not the service architecture. Neither Sirocco nor Triton, to my knowledge, have aspirations (hence requirements) toward providing service to the internet, at large. They both seemed to be aimed at the enterprise level. My worry, my facility's worry, centers around the unintended compromise of information; While it is flowing, while it is at rest. For "while it is flowing", we have chosen to mandate secure transmission channels. Since we don't prescribe the method of security, though, it is difficult to look there for weakness. What is wide open, and seems most likely to me, is a compromise within one or more of the components within the architecture. It is only the client that we cannot control and, so, that seems the best place to look from my perspective. You would do us and our sponsors a great benefit if you could prove that it is impossible to compromise information stored outside of the clients or identify the weaknesses, and suggest solutions, relative to how such a compromise might be achieved. --Lee
On 08/02/2012 11:21 AM, Ward, Lee wrote:
On Aug 2, 2012, at 9:01 AM, Phil Carns wrote:
On 08/01/2012 02:01 PM, Dries Kimpe wrote:
----> Denial of service and related events are basically accounting
for 50% of yr3, 33% of yr 4 and 50% of yr 5 (with yr 4 and yr 5 being the same deliverable). Can we really justify so much effort to this one topic? Is it an issue in similar storage systems? For example, do lustre/gpfs/... have anything in this area and if not, are they looking into adding this? Given the intended deployment of the storage system, there might be other areas that could provide more benefit? Do you have suggestions for anything you might find more useful? That would be welcome. Coming up with 5 year plans with a one day turn around is challenging. Ideas from you are very welcome at this point.... Unfortunately, no.:( The only thing I can come up with now is to investigate and implement the authorization for the other frontends we would support? (i.e. for posix for example), but not sure if this makes a good deliverable.
(It is something we need though).
Ideas/suggestions from other people?
Dries
I'm rather late commenting on this, and I'm no security expert, but from my perspective I agree with the notion of de-emphasizing the DOS stuff in favor of other topics. I've always had the impression that DOS problems seem more critical to storage systems (or other services) that are open to the Internet at large. For the type of storage system we are building, I would expect things like unauthorized data access, how to tie in with external auth mechanisms, and how to migrate data on and off of storage safely to be bigger concerns.
Some level of DOS exploration is good though, especially if there is some potential (for example) for an application to use DOS as a tool towards gaining unauthorized access, though. I don't know if that's a plausible possibility or not.
Agreed. Were I reviewing this program I would ask for our thinking here; Why are we paying so much attention to this for a system that will run only on networks over which absolute, dictatorial, control exists.
Our risk is the compromise of information by the insider. That, by far, is the number one, most, consequential event that I can imagine. From that, it seems reasonable to conclude that the end-point of an attack lies at the hosts in the network, that the infrastructure is unreasonably difficult to leverage for an attack. Are we paying enough attention to the hosts? Are we confident we know the vectors, there? Are we confident we can defend against those vectors?
Were I a reviewer…
--Lee
-Phil _______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
-- =================== R. R. Brooks
Associate Professor Holcombe Department of Electrical and Computer Engineering Clemson University
313-C Riggs Hall PO Box 340915 Clemson, SC 29634-0915 USA
Tel. 864-656-0920 Fax. 864-656-5910 email: [email protected] web: http://www.clemson.edu/~rrb
_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
Modifications on my bullets based on Lee's and Phil's coments. On 08/02/2012 01:45 PM, Ward, Lee wrote:
On Aug 2, 2012, at 10:39 AM, Richard Brooks wrote:
Am revising my inputs.
The logic behind looking at denial of service was that denial of service can also be looked at as compromising quality of service.
You look at the system and see if, and under which conditions, it is possible to construct workloads that severely impact performance. In some ways, it is another way of looking at a combination of dependability and scalability. Although it is phrased from an adversarial point of view, in implementation it does not have to be. If pathological uses of the system exists, it will eventually be found by accident (if not on purpose.)
That said, I appreciate the comments and am redrafting my inputs. The comments you have would occur to others.
I would appreciate, though, some feedback as to whether you find the idea of looking for situations that produce bad outcomes reasonable in this context, or not.
I do find the idea of looking for such situations valuable. The context in which such situations might conceivably occur is related to the impact, and so the value of that exploration, though. A DOS attack on our file systems is a low-impact, transient, issue that is easily corrected because the network is managed dictatorially. An offending host or network can be trivially fenced from the infrastructure. A successful DOS attack originating from within an enterprise would be a direct result of naive network management. It would be the management policy requiring attention, not the service architecture. Neither Sirocco nor Triton, to my knowledge, have aspirations (hence requirements) toward providing service to the internet, at large. They both seemed to be aimed at the enterprise level.
My worry, my facility's worry, centers around the unintended compromise of information; While it is flowing, while it is at rest. For "while it is flowing", we have chosen to mandate secure transmission channels. Since we don't prescribe the method of security, though, it is difficult to look there for weakness. What is wide open, and seems most likely to me, is a compromise within one or more of the components within the architecture. It is only the client that we cannot control and, so, that seems the best place to look from my perspective. You would do us and our sponsors a great benefit if you could prove that it is impossible to compromise information stored outside of the clients or identify the weaknesses, and suggest solutions, relative to how such a compromise might be achieved.
--Lee
On 08/02/2012 11:21 AM, Ward, Lee wrote:
On Aug 2, 2012, at 9:01 AM, Phil Carns wrote:
On 08/01/2012 02:01 PM, Dries Kimpe wrote:
----> Denial of service and related events are basically accounting
for 50% of yr3, 33% of yr 4 and 50% of yr 5 (with yr 4 and yr 5 being the same deliverable). Can we really justify so much effort to this one topic? Is it an issue in similar storage systems? For example, do lustre/gpfs/... have anything in this area and if not, are they looking into adding this? Given the intended deployment of the storage system, there might be other areas that could provide more benefit? Do you have suggestions for anything you might find more useful? That would be welcome. Coming up with 5 year plans with a one day turn around is challenging. Ideas from you are very welcome at this point.... Unfortunately, no.:( The only thing I can come up with now is to investigate and implement the authorization for the other frontends we would support? (i.e. for posix for example), but not sure if this makes a good deliverable.
(It is something we need though).
Ideas/suggestions from other people?
Dries
I'm rather late commenting on this, and I'm no security expert, but from my perspective I agree with the notion of de-emphasizing the DOS stuff in favor of other topics. I've always had the impression that DOS problems seem more critical to storage systems (or other services) that are open to the Internet at large. For the type of storage system we are building, I would expect things like unauthorized data access, how to tie in with external auth mechanisms, and how to migrate data on and off of storage safely to be bigger concerns.
Some level of DOS exploration is good though, especially if there is some potential (for example) for an application to use DOS as a tool towards gaining unauthorized access, though. I don't know if that's a plausible possibility or not.
Agreed. Were I reviewing this program I would ask for our thinking here; Why are we paying so much attention to this for a system that will run only on networks over which absolute, dictatorial, control exists.
Our risk is the compromise of information by the insider. That, by far, is the number one, most, consequential event that I can imagine. From that, it seems reasonable to conclude that the end-point of an attack lies at the hosts in the network, that the infrastructure is unreasonably difficult to leverage for an attack. Are we paying enough attention to the hosts? Are we confident we know the vectors, there? Are we confident we can defend against those vectors?
Were I a reviewer�
--Lee
-Phil _______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
-- =================== R. R. Brooks
Associate Professor Holcombe Department of Electrical and Computer Engineering Clemson University
313-C Riggs Hall PO Box 340915 Clemson, SC 29634-0915 USA
Tel. 864-656-0920 Fax. 864-656-5910 email: [email protected] web: http://www.clemson.edu/~rrb
_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
-- =================== R. R. Brooks Associate Professor Holcombe Department of Electrical and Computer Engineering Clemson University 313-C Riggs Hall PO Box 340915 Clemson, SC 29634-0915 USA Tel. 864-656-0920 Fax. 864-656-5910 email: [email protected] web: http://www.clemson.edu/~rrb
Hi Lee, Here are the things ORNL plans to build as part of this effort. Year 1 -- Initial prototype design for moving sw analytics close to storage resources Year 2 -- Proper prototype implementation of migrating sw analytics onto storage resources Year 3 -- Initial prototype design for extending memory-space onto storage system resources Year 4 -- Proper prototype implementation for extending memory-space onto storage system resources Year 5 -- Initial programming language extensions capable of mapping variables, etc onto storage resources If you want it in a text document, I can do that also. Cheers, Brad On 8/2/12 2:11 PM, "Richard Brooks" <[email protected]> wrote:
Modifications on my bullets based on Lee's and Phil's coments.
On 08/02/2012 01:45 PM, Ward, Lee wrote:
On Aug 2, 2012, at 10:39 AM, Richard Brooks wrote:
Am revising my inputs.
The logic behind looking at denial of service was that denial of service can also be looked at as compromising quality of service.
You look at the system and see if, and under which conditions, it is possible to construct workloads that severely impact performance. In some ways, it is another way of looking at a combination of dependability and scalability. Although it is phrased from an adversarial point of view, in implementation it does not have to be. If pathological uses of the system exists, it will eventually be found by accident (if not on purpose.)
That said, I appreciate the comments and am redrafting my inputs. The comments you have would occur to others.
I would appreciate, though, some feedback as to whether you find the idea of looking for situations that produce bad outcomes reasonable in this context, or not.
I do find the idea of looking for such situations valuable. The context in which such situations might conceivably occur is related to the impact, and so the value of that exploration, though. A DOS attack on our file systems is a low-impact, transient, issue that is easily corrected because the network is managed dictatorially. An offending host or network can be trivially fenced from the infrastructure. A successful DOS attack originating from within an enterprise would be a direct result of naive network management. It would be the management policy requiring attention, not the service architecture. Neither Sirocco nor Triton, to my knowledge, have aspirations (hence requirements) toward providing service to the internet, at large. They both seemed to be aimed at the enterprise level.
My worry, my facility's worry, centers around the unintended compromise of information; While it is flowing, while it is at rest. For "while it is flowing", we have chosen to mandate secure transmission channels. Since we don't prescribe the method of security, though, it is difficult to look there for weakness. What is wide open, and seems most likely to me, is a compromise within one or more of the components within the architecture. It is only the client that we cannot control and, so, that seems the best place to look from my perspective. You would do us and our sponsors a great benefit if you could prove that it is impossible to compromise information stored outside of the clients or identify the weaknesses, and suggest solutions, relative to how such a compromise might be achieved.
--Lee
On 08/02/2012 11:21 AM, Ward, Lee wrote:
On Aug 2, 2012, at 9:01 AM, Phil Carns wrote:
On 08/01/2012 02:01 PM, Dries Kimpe wrote:
----> Denial of service and related events are basically accounting
for 50% of yr3, 33% of yr 4 and 50% of yr 5 (with yr 4 and yr 5 being the same deliverable). Can we really justify so much effort to this one topic? Is it an issue in similar storage systems? For example, do lustre/gpfs/... have anything in this area and if not, are they looking into adding this? Given the intended deployment of the storage system, there might be other areas that could provide more benefit? Do you have suggestions for anything you might find more useful? That would be welcome. Coming up with 5 year plans with a one day turn around is challenging. Ideas from you are very welcome at this point.... Unfortunately, no.:( The only thing I can come up with now is to investigate and implement the authorization for the other frontends we would support? (i.e. for posix for example), but not sure if this makes a good deliverable.
(It is something we need though).
Ideas/suggestions from other people?
Dries
I'm rather late commenting on this, and I'm no security expert, but from my perspective I agree with the notion of de-emphasizing the DOS stuff in favor of other topics. I've always had the impression that DOS problems seem more critical to storage systems (or other services) that are open to the Internet at large. For the type of storage system we are building, I would expect things like unauthorized data access, how to tie in with external auth mechanisms, and how to migrate data on and off of storage safely to be bigger concerns.
Some level of DOS exploration is good though, especially if there is some potential (for example) for an application to use DOS as a tool towards gaining unauthorized access, though. I don't know if that's a plausible possibility or not.
Agreed. Were I reviewing this program I would ask for our thinking here; Why are we paying so much attention to this for a system that will run only on networks over which absolute, dictatorial, control exists.
Our risk is the compromise of information by the insider. That, by far, is the number one, most, consequential event that I can imagine. From that, it seems reasonable to conclude that the end-point of an attack lies at the hosts in the network, that the infrastructure is unreasonably difficult to leverage for an attack. Are we paying enough attention to the hosts? Are we confident we know the vectors, there? Are we confident we can defend against those vectors?
Were I a reviewerŠ
--Lee
-Phil _______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
-- =================== R. R. Brooks
Associate Professor Holcombe Department of Electrical and Computer Engineering Clemson University
313-C Riggs Hall PO Box 340915 Clemson, SC 29634-0915 USA
Tel. 864-656-0920 Fax. 864-656-5910 email: [email protected] web: http://www.clemson.edu/~rrb
_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
-- =================== R. R. Brooks
Associate Professor Holcombe Department of Electrical and Computer Engineering Clemson University
313-C Riggs Hall PO Box 340915 Clemson, SC 29634-0915 USA
Tel. 864-656-0920 Fax. 864-656-5910 email: [email protected] web: http://www.clemson.edu/~rrb
Looks pretty good to me, Brad. I'm thinking this list maps 1:1 in both the 5-year-plan and software artifacts document. Only difference is in how we say it, in the 5-year plan it's "exploring…" and in the artifacts document we describe them as "features supporting…". About right? --Lee On Aug 2, 2012, at 2:08 PM, Settlemyer, Bradley W. wrote:
Hi Lee,
Here are the things ORNL plans to build as part of this effort.
Year 1 -- Initial prototype design for moving sw analytics close to storage resources
Year 2 -- Proper prototype implementation of migrating sw analytics onto storage resources
Year 3 -- Initial prototype design for extending memory-space onto storage system resources
Year 4 -- Proper prototype implementation for extending memory-space onto storage system resources
Year 5 -- Initial programming language extensions capable of mapping variables, etc onto storage resources
If you want it in a text document, I can do that also.
Cheers, Brad
On 8/2/12 2:11 PM, "Richard Brooks" <[email protected]> wrote:
Modifications on my bullets based on Lee's and Phil's coments.
On 08/02/2012 01:45 PM, Ward, Lee wrote:
On Aug 2, 2012, at 10:39 AM, Richard Brooks wrote:
Am revising my inputs.
The logic behind looking at denial of service was that denial of service can also be looked at as compromising quality of service.
You look at the system and see if, and under which conditions, it is possible to construct workloads that severely impact performance. In some ways, it is another way of looking at a combination of dependability and scalability. Although it is phrased from an adversarial point of view, in implementation it does not have to be. If pathological uses of the system exists, it will eventually be found by accident (if not on purpose.)
That said, I appreciate the comments and am redrafting my inputs. The comments you have would occur to others.
I would appreciate, though, some feedback as to whether you find the idea of looking for situations that produce bad outcomes reasonable in this context, or not.
I do find the idea of looking for such situations valuable. The context in which such situations might conceivably occur is related to the impact, and so the value of that exploration, though. A DOS attack on our file systems is a low-impact, transient, issue that is easily corrected because the network is managed dictatorially. An offending host or network can be trivially fenced from the infrastructure. A successful DOS attack originating from within an enterprise would be a direct result of naive network management. It would be the management policy requiring attention, not the service architecture. Neither Sirocco nor Triton, to my knowledge, have aspirations (hence requirements) toward providing service to the internet, at large. They both seemed to be aimed at the enterprise level.
My worry, my facility's worry, centers around the unintended compromise of information; While it is flowing, while it is at rest. For "while it is flowing", we have chosen to mandate secure transmission channels. Since we don't prescribe the method of security, though, it is difficult to look there for weakness. What is wide open, and seems most likely to me, is a compromise within one or more of the components within the architecture. It is only the client that we cannot control and, so, that seems the best place to look from my perspective. You would do us and our sponsors a great benefit if you could prove that it is impossible to compromise information stored outside of the clients or identify the weaknesses, and suggest solutions, relative to how such a compromise might be achieved.
--Lee
On 08/02/2012 11:21 AM, Ward, Lee wrote:
On Aug 2, 2012, at 9:01 AM, Phil Carns wrote:
On 08/01/2012 02:01 PM, Dries Kimpe wrote:
----> Denial of service and related events are basically accounting
for 50% of yr3, 33% of yr 4 and 50% of yr 5 (with yr 4 and yr 5 being the same deliverable). Can we really justify so much effort to this one topic? Is it an issue in similar storage systems? For example, do lustre/gpfs/... have anything in this area and if not, are they looking into adding this? Given the intended deployment of the storage system, there might be other areas that could provide more benefit? Do you have suggestions for anything you might find more useful? That would be welcome. Coming up with 5 year plans with a one day turn around is challenging. Ideas from you are very welcome at this point.... Unfortunately, no.:( The only thing I can come up with now is to investigate and implement the authorization for the other frontends we would support? (i.e. for posix for example), but not sure if this makes a good deliverable.
(It is something we need though).
Ideas/suggestions from other people?
Dries
I'm rather late commenting on this, and I'm no security expert, but from my perspective I agree with the notion of de-emphasizing the DOS stuff in favor of other topics. I've always had the impression that DOS problems seem more critical to storage systems (or other services) that are open to the Internet at large. For the type of storage system we are building, I would expect things like unauthorized data access, how to tie in with external auth mechanisms, and how to migrate data on and off of storage safely to be bigger concerns.
Some level of DOS exploration is good though, especially if there is some potential (for example) for an application to use DOS as a tool towards gaining unauthorized access, though. I don't know if that's a plausible possibility or not.
Agreed. Were I reviewing this program I would ask for our thinking here; Why are we paying so much attention to this for a system that will run only on networks over which absolute, dictatorial, control exists.
Our risk is the compromise of information by the insider. That, by far, is the number one, most, consequential event that I can imagine. From that, it seems reasonable to conclude that the end-point of an attack lies at the hosts in the network, that the infrastructure is unreasonably difficult to leverage for an attack. Are we paying enough attention to the hosts? Are we confident we know the vectors, there? Are we confident we can defend against those vectors?
Were I a reviewerŠ
--Lee
-Phil _______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
-- =================== R. R. Brooks
Associate Professor Holcombe Department of Electrical and Computer Engineering Clemson University
313-C Riggs Hall PO Box 340915 Clemson, SC 29634-0915 USA
Tel. 864-656-0920 Fax. 864-656-5910 email: [email protected] web: http://www.clemson.edu/~rrb
_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
-- =================== R. R. Brooks
Associate Professor Holcombe Department of Electrical and Computer Engineering Clemson University
313-C Riggs Hall PO Box 340915 Clemson, SC 29634-0915 USA
Tel. 864-656-0920 Fax. 864-656-5910 email: [email protected] web: http://www.clemson.edu/~rrb
I was meeting the most pressing need first (what the customer asked for). Here is a 5 year plan with deliverables + software for ORNL: Year 1 ------ - Initial prototype design for moving sw analytics close to storage resources - Report describing Exascale storage use cases, and how to effectively construct analytics for these use cases - Report comparing data resilience approaches for Exascale storage Year 2 ------ - Proper prototype implementation of migrating sw analytics onto storage Resources - Report describing requirements and techniques for extending program memory space seamlessly into storage system Year 3 ------ - Initial prototype design for extending memory-space onto storage system resources - Report describing impacts of migrating analytics into storage Year 4 ------ - Proper prototype implementation for extending memory-space onto storage system resources - Report evaluating performance impacts of extending memory-space to storage system for Exascale use cases Year 5 ------ - Initial prototype programming language extensions capable of mapping variables, etc onto storage resources - Report describing programming language extensions that map variables, etc. onto storage resources On 8/2/12 4:29 PM, "Ward, Lee" <[email protected]> wrote:
Looks pretty good to me, Brad. I'm thinking this list maps 1:1 in both the 5-year-plan and software artifacts document. Only difference is in how we say it, in the 5-year plan it's "exploring..." and in the artifacts document we describe them as "features supporting...". About right?
--Lee
On Aug 2, 2012, at 2:08 PM, Settlemyer, Bradley W. wrote:
Hi Lee,
Here are the things ORNL plans to build as part of this effort.
Year 1 -- Initial prototype design for moving sw analytics close to storage resources
Year 2 -- Proper prototype implementation of migrating sw analytics onto storage resources
Year 3 -- Initial prototype design for extending memory-space onto storage system resources
Year 4 -- Proper prototype implementation for extending memory-space onto storage system resources
Year 5 -- Initial programming language extensions capable of mapping variables, etc onto storage resources
If you want it in a text document, I can do that also.
Cheers, Brad
On 8/2/12 2:11 PM, "Richard Brooks" <[email protected]> wrote:
Modifications on my bullets based on Lee's and Phil's coments.
On 08/02/2012 01:45 PM, Ward, Lee wrote:
On Aug 2, 2012, at 10:39 AM, Richard Brooks wrote:
Am revising my inputs.
The logic behind looking at denial of service was that denial of service can also be looked at as compromising quality of service.
You look at the system and see if, and under which conditions, it is possible to construct workloads that severely impact performance. In some ways, it is another way of looking at a combination of dependability and scalability. Although it is phrased from an adversarial point of view, in implementation it does not have to be. If pathological uses of the system exists, it will eventually be found by accident (if not on purpose.)
That said, I appreciate the comments and am redrafting my inputs. The comments you have would occur to others.
I would appreciate, though, some feedback as to whether you find the idea of looking for situations that produce bad outcomes reasonable in this context, or not.
I do find the idea of looking for such situations valuable. The context in which such situations might conceivably occur is related to the impact, and so the value of that exploration, though. A DOS attack on our file systems is a low-impact, transient, issue that is easily corrected because the network is managed dictatorially. An offending host or network can be trivially fenced from the infrastructure. A successful DOS attack originating from within an enterprise would be a direct result of naive network management. It would be the management policy requiring attention, not the service architecture. Neither Sirocco nor Triton, to my knowledge, have aspirations (hence requirements) toward providing service to the internet, at large. They both seemed to be aimed at the enterprise level.
My worry, my facility's worry, centers around the unintended compromise of information; While it is flowing, while it is at rest. For "while it is flowing", we have chosen to mandate secure transmission channels. Since we don't prescribe the method of security, though, it is difficult to look there for weakness. What is wide open, and seems most likely to me, is a compromise within one or more of the components within the architecture. It is only the client that we cannot control and, so, that seems the best place to look from my perspective. You would do us and our sponsors a great benefit if you could prove that it is impossible to compromise information stored outside of the clients or identify the weaknesses, and suggest solutions, relative to how such a compromise might be achieved.
--Lee
On 08/02/2012 11:21 AM, Ward, Lee wrote:
On Aug 2, 2012, at 9:01 AM, Phil Carns wrote:
On 08/01/2012 02:01 PM, Dries Kimpe wrote:
----> Denial of service and related events are basically accounting
for 50% of yr3, 33% of yr 4 and 50% of yr 5 (with yr 4 and yr 5 being the same deliverable). Can we really justify so much effort to this one topic? Is it an issue in similar storage systems? For example, do lustre/gpfs/... have anything in this area and if not, are they looking into adding this? Given the intended deployment of the storage system, there might be other areas that could provide more benefit? Do you have suggestions for anything you might find more useful? That would be welcome. Coming up with 5 year plans with a one day turn around is challenging. Ideas from you are very welcome at this point.... Unfortunately, no.:( The only thing I can come up with now is to investigate and implement the authorization for the other frontends we would support? (i.e. for posix for example), but not sure if this makes a good deliverable.
(It is something we need though).
Ideas/suggestions from other people?
Dries
I'm rather late commenting on this, and I'm no security expert, but from my perspective I agree with the notion of de-emphasizing the DOS stuff in favor of other topics. I've always had the impression that DOS problems seem more critical to storage systems (or other services) that are open to the Internet at large. For the type of storage system we are building, I would expect things like unauthorized data access, how to tie in with external auth mechanisms, and how to migrate data on and off of storage safely to be bigger concerns.
Some level of DOS exploration is good though, especially if there is some potential (for example) for an application to use DOS as a tool towards gaining unauthorized access, though. I don't know if that's a plausible possibility or not.
Agreed. Were I reviewing this program I would ask for our thinking here; Why are we paying so much attention to this for a system that will run only on networks over which absolute, dictatorial, control exists.
Our risk is the compromise of information by the insider. That, by far, is the number one, most, consequential event that I can imagine. From that, it seems reasonable to conclude that the end-point of an attack lies at the hosts in the network, that the infrastructure is unreasonably difficult to leverage for an attack. Are we paying enough attention to the hosts? Are we confident we know the vectors, there? Are we confident we can defend against those vectors?
Were I a reviewerŠ
--Lee
-Phil _______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
-- =================== R. R. Brooks
Associate Professor Holcombe Department of Electrical and Computer Engineering Clemson University
313-C Riggs Hall PO Box 340915 Clemson, SC 29634-0915 USA
Tel. 864-656-0920 Fax. 864-656-5910 email: [email protected] web: http://www.clemson.edu/~rrb
_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
-- =================== R. R. Brooks
Associate Professor Holcombe Department of Electrical and Computer Engineering Clemson University
313-C Riggs Hall PO Box 340915 Clemson, SC 29634-0915 USA
Tel. 864-656-0920 Fax. 864-656-5910 email: [email protected] web: http://www.clemson.edu/~rrb
Even better, thanks. --Lee On Aug 2, 2012, at 3:12 PM, Settlemyer, Bradley W. wrote:
I was meeting the most pressing need first (what the customer asked for). Here is a 5 year plan with deliverables + software for ORNL:
Year 1 ------ - Initial prototype design for moving sw analytics close to storage resources - Report describing Exascale storage use cases, and how to effectively construct analytics for these use cases - Report comparing data resilience approaches for Exascale storage
Year 2 ------ - Proper prototype implementation of migrating sw analytics onto storage Resources - Report describing requirements and techniques for extending program memory space seamlessly into storage system
Year 3 ------ - Initial prototype design for extending memory-space onto storage system resources - Report describing impacts of migrating analytics into storage
Year 4 ------ - Proper prototype implementation for extending memory-space onto storage system resources - Report evaluating performance impacts of extending memory-space to storage system for Exascale use cases
Year 5 ------ - Initial prototype programming language extensions capable of mapping variables, etc onto storage resources - Report describing programming language extensions that map variables, etc. onto storage resources
On 8/2/12 4:29 PM, "Ward, Lee" <[email protected]> wrote:
Looks pretty good to me, Brad. I'm thinking this list maps 1:1 in both the 5-year-plan and software artifacts document. Only difference is in how we say it, in the 5-year plan it's "exploring..." and in the artifacts document we describe them as "features supporting...". About right?
--Lee
On Aug 2, 2012, at 2:08 PM, Settlemyer, Bradley W. wrote:
Hi Lee,
Here are the things ORNL plans to build as part of this effort.
Year 1 -- Initial prototype design for moving sw analytics close to storage resources
Year 2 -- Proper prototype implementation of migrating sw analytics onto storage resources
Year 3 -- Initial prototype design for extending memory-space onto storage system resources
Year 4 -- Proper prototype implementation for extending memory-space onto storage system resources
Year 5 -- Initial programming language extensions capable of mapping variables, etc onto storage resources
If you want it in a text document, I can do that also.
Cheers, Brad
On 8/2/12 2:11 PM, "Richard Brooks" <[email protected]> wrote:
Modifications on my bullets based on Lee's and Phil's coments.
On 08/02/2012 01:45 PM, Ward, Lee wrote:
On Aug 2, 2012, at 10:39 AM, Richard Brooks wrote:
Am revising my inputs.
The logic behind looking at denial of service was that denial of service can also be looked at as compromising quality of service.
You look at the system and see if, and under which conditions, it is possible to construct workloads that severely impact performance. In some ways, it is another way of looking at a combination of dependability and scalability. Although it is phrased from an adversarial point of view, in implementation it does not have to be. If pathological uses of the system exists, it will eventually be found by accident (if not on purpose.)
That said, I appreciate the comments and am redrafting my inputs. The comments you have would occur to others.
I would appreciate, though, some feedback as to whether you find the idea of looking for situations that produce bad outcomes reasonable in this context, or not.
I do find the idea of looking for such situations valuable. The context in which such situations might conceivably occur is related to the impact, and so the value of that exploration, though. A DOS attack on our file systems is a low-impact, transient, issue that is easily corrected because the network is managed dictatorially. An offending host or network can be trivially fenced from the infrastructure. A successful DOS attack originating from within an enterprise would be a direct result of naive network management. It would be the management policy requiring attention, not the service architecture. Neither Sirocco nor Triton, to my knowledge, have aspirations (hence requirements) toward providing service to the internet, at large. They both seemed to be aimed at the enterprise level.
My worry, my facility's worry, centers around the unintended compromise of information; While it is flowing, while it is at rest. For "while it is flowing", we have chosen to mandate secure transmission channels. Since we don't prescribe the method of security, though, it is difficult to look there for weakness. What is wide open, and seems most likely to me, is a compromise within one or more of the components within the architecture. It is only the client that we cannot control and, so, that seems the best place to look from my perspective. You would do us and our sponsors a great benefit if you could prove that it is impossible to compromise information stored outside of the clients or identify the weaknesses, and suggest solutions, relative to how such a compromise might be achieved.
--Lee
On 08/02/2012 11:21 AM, Ward, Lee wrote:
On Aug 2, 2012, at 9:01 AM, Phil Carns wrote:
On 08/01/2012 02:01 PM, Dries Kimpe wrote:
----> Denial of service and related events are basically accounting
for 50% of yr3, 33% of yr 4 and 50% of yr 5 (with yr 4 and yr 5 being the same deliverable). Can we really justify so much effort to this one topic? Is it an issue in similar storage systems? For example, do lustre/gpfs/... have anything in this area and if not, are they looking into adding this? Given the intended deployment of the storage system, there might be other areas that could provide more benefit? Do you have suggestions for anything you might find more useful? That would be welcome. Coming up with 5 year plans with a one day turn around is challenging. Ideas from you are very welcome at this point.... Unfortunately, no.:( The only thing I can come up with now is to investigate and implement the authorization for the other frontends we would support? (i.e. for posix for example), but not sure if this makes a good deliverable.
(It is something we need though).
Ideas/suggestions from other people?
Dries
I'm rather late commenting on this, and I'm no security expert, but from my perspective I agree with the notion of de-emphasizing the DOS stuff in favor of other topics. I've always had the impression that DOS problems seem more critical to storage systems (or other services) that are open to the Internet at large. For the type of storage system we are building, I would expect things like unauthorized data access, how to tie in with external auth mechanisms, and how to migrate data on and off of storage safely to be bigger concerns.
Some level of DOS exploration is good though, especially if there is some potential (for example) for an application to use DOS as a tool towards gaining unauthorized access, though. I don't know if that's a plausible possibility or not.
Agreed. Were I reviewing this program I would ask for our thinking here; Why are we paying so much attention to this for a system that will run only on networks over which absolute, dictatorial, control exists.
Our risk is the compromise of information by the insider. That, by far, is the number one, most, consequential event that I can imagine. From that, it seems reasonable to conclude that the end-point of an attack lies at the hosts in the network, that the infrastructure is unreasonably difficult to leverage for an attack. Are we paying enough attention to the hosts? Are we confident we know the vectors, there? Are we confident we can defend against those vectors?
Were I a reviewerŠ
--Lee
-Phil _______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
-- =================== R. R. Brooks
Associate Professor Holcombe Department of Electrical and Computer Engineering Clemson University
313-C Riggs Hall PO Box 340915 Clemson, SC 29634-0915 USA
Tel. 864-656-0920 Fax. 864-656-5910 email: [email protected] web: http://www.clemson.edu/~rrb
_______________________________________________ ASG mailing list [email protected] https://lists.mcs.anl.gov/mailman/listinfo/asg
-- =================== R. R. Brooks
Associate Professor Holcombe Department of Electrical and Computer Engineering Clemson University
313-C Riggs Hall PO Box 340915 Clemson, SC 29634-0915 USA
Tel. 864-656-0920 Fax. 864-656-5910 email: [email protected] web: http://www.clemson.edu/~rrb
participants (5)
-
Dries Kimpe -
Phil Carns -
Richard Brooks -
Settlemyer, Bradley W. -
Ward, Lee