Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats
Note: This ballot was opened for revision 15 and is now closed.
(Jon Peterson) Yes
Magnus Westerlund Yes
(Jari Arkko) (was Discuss) No Objection
Comment (2008-06-02 for -** No value found for 'p.get_dochistory.rev' **)
The first comment below is a borderline Discuss, the second is just an opinion. The document speaks of an authorization requirement in many places, and then continues to talk about how TLS is used for authentication: An ENRP server that receives a registration/deregistration MUST NOT create or update state information until it has authorized the requesting entity. TLS is used as the authentication mechanism. Authentication is not the same as authorization. Just having a mutually authenticated TLS session between two nodes does not imply that they are authorized to do anything. You need to specify what the authorization model is and how you implement it through protocols and formats. This does not have to be complicated, maybe its merely the fact that all rserpool devices in one pool have to be assigned to a dedicated CA. Or maybe a list of allowed entities is configured. Or some additional information in the certificates provides authorization data. Much of this is probably in the protocol documents, not in -threats. However, the -threats document should at least specify that the network administrators of a pool need to decide which nodes are authorized to participate in which roles. The document was fairly hard to read, partially because there seemed to be many sections that differed from others in only minor ways. For instance, I think Sections 2.1 - 2.4 could have been combined, and the text could have explained all the issues relating to inappropriate PE registrations.
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Russ Housley) No Objection
(Cullen Jennings) No Objection
(Chris Newman) (was Discuss) No Objection
FYI, I'd like to see a pass fixing the terminology in this document even if the details of which TLS authentication mechanisms are mandatory to implement is put in the protocol document.