Last Call Review of draft-ietf-pcp-proxy-08
review-ietf-pcp-proxy-08-secdir-lc-weiler-2015-07-08-00
| Request | Review of | draft-ietf-pcp-proxy |
|---|---|---|
| Requested rev. | no specific revision (document currently at 09) | |
| Type | Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2015-07-07 | |
| Requested | 2015-06-18 | |
| Authors | Simon Perreault, Mohamed Boucadair, Reinaldo Penno, Dan Wing, Stuart Cheshire | |
| Draft last updated | 2015-07-08 | |
| Completed reviews |
Genart Last Call review of -08 by Joel Halpern
(diff)
Secdir Last Call review of -08 by Samuel Weiler (diff) Opsdir Last Call review of -08 by Mehmet Ersue (diff) |
|
| Assignment | Reviewer | Samuel Weiler |
| State | Completed | |
| Review | review-ietf-pcp-proxy-08-secdir-lc-weiler-2015-07-08 | |
| Reviewed rev. | 08 (document currently at 09) | |
| Review result | Ready | |
| Review completed: | 2015-07-08 |
Review
review-ietf-pcp-proxy-08-secdir-lc-weiler-2015-07-08
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: document is ready for publication (with mild reservation). My thanks to the document editors for producing a readable document. Mild reservation: when I look at the use cases for PCP Proxy in this document (e.g. a consumer router doing NAT, connected to hotel NAT, connected to carrier NAT), it's hard to imagine that operational environment often fitting within the description of PCP's "simple threat model" (RFC6887, section 18.1). And once you reject the simplifying assumptions in that "simple threat model", RFC6877 says PCP needs a security mechanism (section 18.2 of RFC6877). Maybe this document should explicity reinforce that need, perhaps citing and blocking on draft-ietf-pcp-authentication?