Skip to main content

Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats
draft-ietf-rserpool-threats-15

Yes

(Jon Peterson)
(Magnus Westerlund)

No Objection

(Cullen Jennings)
(David Ward)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)

Abstain

(Brian Carpenter)

Note: This ballot was opened for revision 15 and is now closed.

Jon Peterson Former IESG member
Yes
Yes () Unknown

                            
Magnus Westerlund Former IESG member
Yes
Yes () Unknown

                            
Chris Newman Former IESG member
(was Discuss) No Objection
No Objection (2008-06-19) Unknown
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.
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
David Ward Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
(was Discuss) No Objection
No Objection (2008-06-02) Unknown
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.
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
No Objection
No Objection () Unknown

                            
Brian Carpenter Former IESG member
(was Discuss) Abstain
Abstain () Unknown