Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats
RFC 5355

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' **)
No email
send info
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

Comment (2008-06-19)
No email
send info
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.

(Tim Polk) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

(Brian Carpenter) (was Discuss) Abstain