Skip to main content

Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters
draft-ietf-rserpool-common-param-18

Yes

(Magnus Westerlund)

No Objection

(Chris Newman)
(Cullen Jennings)
(David Ward)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Russ Housley)

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

Magnus Westerlund Former IESG member
(was Discuss, Yes) Yes
Yes () Unknown

                            
Chris Newman Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
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
No Objection
No Objection (2008-06-05) Unknown
draft-ietf-rserpool-asap-20.txt: No-Obj
=======================================

Comments:

Section 1:

   When SCTP [RFC4960] is used as the transport layer protocol, ASAP can
   seamlessly incorporate the link-layer redundancy provided by SCTP.

Link layer? Its not just that. I think you mean ... the redundancy
provided by SCTP.

Section 2.2.2:

   Note that deregistration is NOT allowed by proxy, in other words a
   PE may only deregister itself.

I got confused here because at first I thought you had defined a
ASAP proxy role somewhere in the document. However, I think you
simply meant that the PE must de-register its own identifier.
I wonder how to check for this? Is the receiver tracking the
IP address of the sender of the register and de-register? Or
something else? If you can't test it, remove the statement.
Upon reading Section 3.2, I don't think I got any additional
clues about this.

Section 2.2.5:

   Note that if a new Home ENRP server is adopted any 'dynamic update
   request' will need to be resent to the new Home ENPR server if the
   endpoint would like to continue to receive updates.

How does the PU/PE know that a Home ENRP server has been added?

draft-ietf-rserpool-enrp-20.txt: No-Obj
=======================================

Section 3.2.1:

   Note, there is a very remote chance (about 1 in about 4 billion) that
   two ENRP servers in an operational scope will generate the same
   server Id and hence cause a server Id conflict in the pool.  However,
   no severe consequence of such a conflict has been identified.

Hmm. I thought that by the birthday paradox the chances of such a
conflict would be greater. Is there a recovery procedure upon a
conflict? Can the above text be modified to take into account the
paradox? Same issue exists in Section 3.1 of -asap.

draft-ietf-rserpool-common-param-17.txt: Yes
============================================

  This document is in good shape.

draft-ietf-rserpool-policies-09.txt: No-Obj
===========================================

  No comments.

All the documents: 
==================

I am not particularly fond of the security mechanisms. They represent
the "hard-outside-soft-inside" security model. Outsiders will be
unable to pretend to be one of the parties. However, there are no
safeguards with nodes within the system becoming compromised or making
inappropriate actions for their role. For instance, the document does
not define or require the use of certificate fields to bind nodes into
particular addresses or PE/server identifiers.

As an interesting thought experiment, I wonder what RSERPOOL
security would have looked like, if it used HIP-like cryptographic
identities as server/pe identifiers? 

However, I do not recommend the authors do anything abou this. Any
change here would be a major effort and not worth the time at this
stage.
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