Skip to main content

Port Control Protocol (PCP) Server Selection
draft-ietf-pcp-server-selection-10

Yes

(Ted Lemon)

No Objection

(Adrian Farrel)
(Alia Atlas)
(Barry Leiba)
(Benoît Claise)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)

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

Ted Lemon Former IESG member
Yes
Yes (for -08) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2015-01-21 for -08) Unknown
"If the PCP client has exhausted all IP addresses configured for a
       given PCP server, the procedure SHOULD be repeated every fifteen
       (15) minutes until the PCP request is successfully answered."

Is there something that prevents a client from re-trying this procedure endlessly for a server whose whole set of IP addresses remains unresponsive? Phone call to tech support? ;)
Barry Leiba Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Brian Haberman Former IESG member
(was Discuss) No Objection
No Objection (2015-01-22) Unknown
Thanks for addressing these issues.
Jari Arkko Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection () Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-01-21 for -08) Unknown
I support Stephen's comments and think the SecDir reviewer recommendations would be helpful.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (2015-01-21 for -08) Unknown
I support Brian's DISCUSS points, especially the one about one vs. multiple PCP servers.  If the client doesn't know which case it's in, it can't really follow these procedures.
Spencer Dawkins Former IESG member
No Objection
No Objection (2015-01-19 for -08) Unknown
In this text:

   1.  A PCP client should construct a set of candidate source addresses
       (Section 4 of [RFC6724]), based on application input and PCP
       [RFC6887] constraints.  For example, when sending a PEER or a MAP
       with FILTER request for an existing TCP connection, the only
       candidate source address is the source address used for the
       existing TCP connection.  But when sending a MAP request for a
       service that will accept incoming connections, the candidate
       source addresses may be all of the node's IP addresses, or some
       subset of IP addresses on which the service is configured to
       listen.

   2.  The PCP client then sorts the PCP server IP addresses as per
       Section 6 of [RFC6724] using the candidate source addresses
       selected in the previous step as input to the destination address
       selection algorithm.

if I'm understanding this, if multiple PCP clients end up with the same list of candidate source addresses. and then sort the same list into the same order, does that mean they'll tend to select the same IP addresses that have sorted to the front of the list, even though the PCP server has multiple IP addresses, or will something I'm not seeing cause a more balanced load distribution?

Perhaps there are reasons why that's OK, but I thought I should ask ...
Stephen Farrell Former IESG member
No Objection
No Objection (2015-01-21 for -08) Unknown
- I don't get how one can really ensure the restriction
below is satisfied, nor why it's needed. (I do get that some
setups will be able to check that.)

" o  The configuration mechanism must distinguish IP
addresses that belong to the same PCP server."

- The secdir review [1] also makes a resonable point that
explaining the risk (here) of Nonce re-use would be good.

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05355.html