Port Control Protocol (PCP) Authentication Mechanism
RFC 7652
Yes
No Objection
Note: This ballot was opened for revision 12 and is now closed.
Alvaro Retana No Objection
(Brian Haberman; former steering group member) Yes
(Alia Atlas; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
Thanks for addressing Jouni's OPS DIR review.
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) (was Discuss, No Objection) No Objection
Thanks for getting this done. - How would this work in a home network where the f/w is not managed by the ISP and there'd otherwise be no EAP infrastructure? That could be out-of-scope or require some new/odd EAP implementation and no change to this protocol, and that is probably fine, but I do wonder. - 3.3: Is this really needed? I wonder if we could do without it. The protocol would be simpler if this wasn't needed and simpler == more-secure in general. - 5.11: would s/issued the credentials/issued the EAP credentials that will be used to authenticate the client/ be better? As-is, it's a tiny bit confusing maybe. - 6.2: Maybe this is being overly paranoid, but would it be worth saying that in all failure cases when you say discard the message, you mean to not process it's content? With a very perverse reading of the current text, I might be able to argue that I could process the message content first and only then check the authentication afterwards. Yes, that'd be fairly spectacularly dim, but that kind of thing does sometimes happen. (If there's a better place in the draft to put some text on that, that's just fine.)
(Terry Manderson; former steering group member) No Objection
Thanks for addressing an aspect of security in relation to PCP, especially the Advanced Threat Model from RFC6887. I have a few comments 1) I'm sure the RFC editor will pick these up, however there is some comma usage in the document that caused me to re-read some of the paragraphs to understand. The Abstract is one example of this. I'm certainly no expert so perhaps have a skim over this: http://www.grammarbook.com/punctuation/commas.asp 2) s 3.1.1, please consider rewording the text "Section 5.1 updates the PCP request message format to have a result code." to something like "Section 5.1 updates the PCP request message format with result codes for the PCP Authentication mechanism" ...The wording as it stands seems a little non-specific. 3) Basic DoS attacks (such as state bloat) are mentioned in the security section, are there any complex DoS attacks that can be leveraged using the PCP authentication mechanism itself?