Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2012-08-22
15 (System) post-migration administrative database adjustment to the No Objection position for Chris Newman
2012-08-22
15 (System) post-migration administrative database adjustment to the Abstain position for Brian Carpenter
2008-07-23
15 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2008-07-22
15 (System) IANA Action state changed to No IC from In Progress
2008-07-22
15 (System) IANA Action state changed to In Progress
2008-07-22
15 Amy Vezza IESG state changed to Approved-announcement sent
2008-07-22
15 Amy Vezza IESG has approved the document
2008-07-22
15 Amy Vezza Closed "Approve" ballot
2008-07-22
15 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2008-07-11
15 (System) New version available: draft-ietf-rserpool-threats-15.txt
2008-06-26
15 Chris Newman [Ballot Position Update] Position for Chris Newman has been changed to No Objection from Discuss by Chris Newman
2008-06-24
15 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-06-24
14 (System) New version available: draft-ietf-rserpool-threats-14.txt
2008-06-19
15 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2008-06-19
15 Chris Newman
[Ballot comment]
FYI, I'd like to see a pass fixing the terminology in this document even
if the details of which TLS authentication mechanisms are …
[Ballot comment]
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.
2008-06-19
15 Amy Vezza State Changes to IESG Evaluation from IESG Evaluation - Defer by Amy Vezza
2008-06-19
15 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2008-06-19
15 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2008-06-19
15 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2008-06-19
15 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2008-06-19
15 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2008-06-19
15 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2008-06-18
15 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2008-06-10
13 (System) New version available: draft-ietf-rserpool-threats-13.txt
2008-06-06
15 (System) Removed from agenda for telechat - 2008-06-05
2008-06-04
15 Cullen Jennings State Changes to IESG Evaluation - Defer from IESG Evaluation by Cullen Jennings
2008-06-04
15 Chris Newman
[Ballot discuss]
TLS is not an authentication mechanism.  It is a framework that can be
used to negotiate a security layer.  While the base TLS …
[Ballot discuss]
TLS is not an authentication mechanism.  It is a framework that can be
used to negotiate a security layer.  While the base TLS protocol
specifies a mandatory to implement cipher suite, it does not specify how
a consumer of TLS authenticates either endpoint.  Furthermore, there are
multiple client authentication mechanisms (certificates, PSK) and none
of them are mandatory to implement either in the specification or in
practice with real-world implementations.  So TLS will not interoperate
as an authentication service without a profile specifying how
authentication is done for a particular application of TLS.

In order to use TLS to provide authentication and authorization
services, you need to describe a mandatory-to-implement authentication
mechanism and procedures.  PSK may be appropriate for this particular
application as it may be practical to manually distribute private shared
keys.

Authorization can be implementation specific if authentication is
specified without harming interoperability in my experience.  For PSK,
having a pre-shared-key may constitute acceptable authorization.  For
certificates, being a PE would need a certificate signed by a particular
trusted CA.

Section 2.5.3:

>  as the mutual authentication mechanism.  Any server that presents a
>  valid certificate is allowed to join.

What is a "valid certificate"?  I would argue the certificate one gets
from https://www.yahoo.com/ is a valid certificate.  Thus would yahoo be
able to join anyone's pool with its valid certificate?

Section 6.2.3:

>  The PE MUST authenticate the ENRP server.  TLS is the mechanism used
>  for the authentication.

Using TLS for mutual authentication has been proven to be problematic in
practice.  When the PE's certificate expires does that mean the entire
pool ceases to function immediately?  Or is everyone going to have to
implement an expiration grace period in order to accept the realities of
certificate management.  How long a grace period?  What should the
client do during the grace period?

Section 2.15.3:

>  The requirement is that either the entire ENRP server database MUST
>  be secure, that is, it has registrations exclusively from PEs that
>  have used security mechanisms or the entire database MUST be
>  insecure, that is, registrations are from PEs that have used no
>  security mechanisms.  ENRP servers that support security MUST reject
>  any PE server registration that does not use the security mechanisms.
>  Likewise, ENRP servers that support security MUST NOT accept updates
>  from other ENRP servers that do not use security mechanisms.  TLS is
>  used as the security mechanism so any information not sent using TLS
>  to a secure ENRP server MUST be rejected.

This is really oddly worded and seems counter-productive to me.  I'd say
the requirement is all ENRP server databases MUST implement a security
policy that requires use of TLS + endpoint authentication (as specified)
+ a particular cipher strength.  Then ENRP server databases MAY
implement additional security policies (e.g. allow weaker cipher suites,
mandate stronger cipher suites, no authentication, etc).  I don't see
any benefit to constraining security policy beyond having one that's
mandatory-to-implement.  A policy I would find particularly useful would
be one where database entries are marked as trusted or not.  Once an
entry is marked as trusted it can only be updated by a connection with
acceptable security (e.g. TLS, proper client auth and cipher suite).
This would be great for transitioning a pool of servers from not-trusted
to trusted over time and getting benefit as soon as the first server is
transitioned.  Just an example of a useful policy that shouldn't be
prohibited.  A similar policy could apply to cipher or hash upgrades
within TLS.
2008-06-04
15 Chris Newman [Ballot Position Update] New position, Discuss, has been recorded by Chris Newman
2008-06-02
15 Jari Arkko
[Ballot comment]
The first comment below is a borderline Discuss, the second is
just an opinion.

The document speaks of an authorization requirement in many …
[Ballot comment]
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.
2008-06-02
15 Jari Arkko
[Ballot comment]
The document speaks of an authorization requirement in many places,
and then continues to talk about how TLS is used for authentication:

  …
[Ballot comment]
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.
2008-06-02
15 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2008-06-02
15 Jari Arkko [Ballot discuss]
2008-06-02
15 Jari Arkko
[Ballot comment]
The document was fairly hard to read, partially because there
seemed to be many sections that differed from others in only
minor ways. …
[Ballot comment]
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.
2008-06-02
15 Jari Arkko
[Ballot discuss]
This is a discuss-discuss; I have not read the other rserpool documents
yet and it may be that the others already provide the …
[Ballot discuss]
This is a discuss-discuss; I have not read the other rserpool documents
yet and it may be that the others already provide the content that
seems to be missing here. But:

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.
2008-06-02
15 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2008-05-30
15 Magnus Westerlund [Ballot Position Update] New position, Yes, has been recorded for Magnus Westerlund
2008-05-30
15 Magnus Westerlund Ballot has been issued by Magnus Westerlund
2008-05-30
15 Magnus Westerlund State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Magnus Westerlund
2008-05-30
15 Magnus Westerlund Placed on agenda for telechat - 2008-06-05 by Magnus Westerlund
2008-05-30
15 Magnus Westerlund [Note]: 'PROTO Shepherd: Maureen Stillman
Please read RSERPOOL Overview document and the protocol specifications first.' added by Magnus Westerlund
2008-05-06
12 (System) New version available: draft-ietf-rserpool-threats-12.txt
2008-04-28
11 (System) New version available: draft-ietf-rserpool-threats-11.txt
2008-04-26
15 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Patrick Cain.
2008-04-24
10 (System) New version available: draft-ietf-rserpool-threats-10.txt
2008-04-14
15 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-04-10
15 Amanda Baber IANA Last Call comments:

As described in the IANA Considerations section, we understand this document
to have NO IANA Actions.
2008-04-03
15 Samuel Weiler Request for Last Call review by SECDIR is assigned to Patrick Cain
2008-04-03
15 Samuel Weiler Request for Last Call review by SECDIR is assigned to Patrick Cain
2008-03-31
15 Amy Vezza Last call sent
2008-03-31
15 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-03-31
15 Magnus Westerlund State Changes to Last Call Requested from AD Evaluation::AD Followup by Magnus Westerlund
2008-03-31
15 Magnus Westerlund Last Call was requested by Magnus Westerlund
2007-10-24
15 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-10-24
09 (System) New version available: draft-ietf-rserpool-threats-09.txt
2007-10-23
15 Magnus Westerlund State Change Notice email list have been change to <lyong@ciena.com>, <maureen.stillman@nokia.com>,draft-ietf-rserpool-threats@tools.ietf.org from <lyong@ciena.com>, <maureen.stillman@nokia.com>
2007-10-23
15 Magnus Westerlund State Changes to AD Evaluation::Revised ID Needed from Publication Requested by Magnus Westerlund
2007-10-22
15 Dinara Suleymanova
PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, …
PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

I (Lyndon Ong) am Document Shepherd for the draft. I believe this version is ready for forwarding to IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has been reviewed by key WG members.

We have had a number of non-WG members read over the threats draft, including Brian Carpenter and Jon Peterson, both of whom found the draft acceptable.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

No concerns that we know of.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

There are no IPR filings on the document.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is strong WG consensus on the document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No one has threatened an appeal or otherwise objected.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

Nit checker has been run on the document successfully, except that three extraneous references were identified (listed under references but not actually used in the text). These can be removed in an updated version of the draft or in RFC editing. This draft is informational only.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes, references are split as required.

(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

There are no IANA considerations required for this draft.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There are no sections written in a formal language.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This draft provides an analysis of security threats to the Rserpool architecture and defines requirements for countering these threats. It provides additional information supporting the security sections of the Rserpool protocol documents.

Working Group Summary

The Working Group process was constrained by the relatively small number of people actively involved (although those involved were committed to doing implementations of the protocols). Otherwise there was little controversy within the group.

Document Quality

There are multiple implementations of the Rserpool protocols, ENRP and ASAP. However, there are no vendors that have indicated plans for implementation, and the protocols are being proposed as Experimental. This particular draft is Informational only, as it defines no new protocol.

Personnel

Document Shepherding is being provided by the non-author Working Group chair, Lyndon Ong. Responsible Area Director is Magnus Westerland.
2007-10-22
15 Dinara Suleymanova State Changes to Publication Requested from AD is watching by Dinara Suleymanova
2007-09-19
08 (System) New version available: draft-ietf-rserpool-threats-08.txt
2007-09-11
15 (System) State Changes to AD is watching from Dead by system
2007-09-10
07 (System) New version available: draft-ietf-rserpool-threats-07.txt
2007-05-20
15 (System) State Changes to Dead from AD is watching by system
2007-05-20
15 (System) Document has expired
2006-12-18
15 Brian Carpenter [Ballot Position Update] Position for Brian Carpenter has been changed to Abstain from Discuss by Brian Carpenter
2006-12-18
15 Magnus Westerlund Merged with draft-ietf-rserpool-arch by Magnus Westerlund
2006-11-17
15 (System) State Changes to AD is watching from Dead by system
2006-11-16
06 (System) New version available: draft-ietf-rserpool-threats-06.txt
2006-07-13
15 (System) State Changes to Dead from AD is watching by system
2006-07-13
15 (System) Document has expired
2006-07-12
15 Magnus Westerlund State Changes to AD is watching from AD Evaluation::AD Followup by Magnus Westerlund
2006-05-18
15 Magnus Westerlund State Changes to AD Evaluation::AD Followup from IESG Evaluation::Point Raised - writeup needed by Magnus Westerlund
2005-10-12
15 Jon Peterson State Changes to IESG Evaluation::Point Raised - writeup needed from IESG Evaluation by Jon Peterson
2005-10-11
15 Jon Peterson Removed from agenda for telechat - 2005-10-13 by Jon Peterson
2005-10-11
15 (System) State Changes to IESG Evaluation from IESG Evaluation - Defer by system
2005-09-28
15 Michelle Cotton IANA Comments:
As described in the IANA Considerations section, we understand this document to have NO IANA Actions.
2005-09-28
15 Sam Hartman State Changes to IESG Evaluation - Defer from Waiting for Writeup by Sam Hartman
2005-09-27
15 Brian Carpenter [Ballot Position Update] New position, Discuss, has been recorded for Brian Carpenter by Brian Carpenter
2005-09-26
15 Jon Peterson [Ballot Position Update] New position, Yes, has been recorded for Jon Peterson
2005-09-26
15 Jon Peterson Ballot has been issued by Jon Peterson
2005-09-26
15 Jon Peterson Created "Approve" ballot
2005-09-26
15 (System) Ballot writeup text was added
2005-09-26
15 (System) Last call text was added
2005-09-26
15 (System) Ballot approval text was added
2005-09-22
15 Jon Peterson Placed on agenda for telechat - 2005-09-29 by Jon Peterson
2005-07-14
15 Jon Peterson Merged with draft-ietf-rserpool-arch by Jon Peterson
2005-07-14
15 Jon Peterson State Changes to Waiting for Writeup from AD Evaluation::AD Followup by Jon Peterson
2005-07-14
15 Jon Peterson [Note]: 'PROTO Shepherd: Maureen Stillman' added by Jon Peterson
2005-07-08
05 (System) New version available: draft-ietf-rserpool-threats-05.txt
2005-01-07
04 (System) New version available: draft-ietf-rserpool-threats-04.txt
2004-07-09
15 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-07-09
03 (System) New version available: draft-ietf-rserpool-threats-03.txt
2004-01-19
15 Jon Peterson State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jon Peterson
2003-11-25
15 Jon Peterson State Changes to AD Evaluation from Publication Requested by Jon Peterson
2003-10-14
15 Dinara Suleymanova Draft Added by Dinara Suleymanova
2003-10-07
02 (System) New version available: draft-ietf-rserpool-threats-02.txt
2003-08-25
01 (System) New version available: draft-ietf-rserpool-threats-01.txt
2002-12-12
00 (System) New version available: draft-ietf-rserpool-threats-00.txt