I have some contrary thoughts on the AAA section of this document. Section 4.1 tries to describe requirements wherein the I2RS Clients may request for subsets of AAA policy to be exported to the Client so that the client may enforce them. While this seems like a nice way to scale the operations, in some cases disclosing those policies (even if we find a good way to encode the AAA validation in a generic enough way to distribute) may accidentally disclose information that is otherwise intended to be secure.
I would seek comment from the security directorate, but I suspect we don't want to do this. But in section 4.4, we try to discuss availability. The first sentence immediately says "enforcement should not remain local", while one way to enable security in some environments is to distribute and synchronize policy to be enforced locally. It then goes on to talk about general availability mechanisms and then we further dive into security against DoS. I believe we may be boiling the ocean a bit to try to go into too many details about the design of secure AAA systems. It seems a bit out of scope for I2RS to do such work; we should defer to work done elsewhere on the topic, if it exists. If it doesn't exist, I'm not sure we should do it. What is right for us to point out is, "If we use a remote AAA mechanism, it must be robust in hostile environments". Expand that as you will, but being too proscriptive is not our job. -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
