Telechat Review of draft-weil-shared-transition-space-request-
review-weil-shared-transition-space-request-secdir-telechat-sheffer-2011-08-26-00
Request | Review of | draft-weil-shared-transition-space-request |
---|---|---|
Requested revision | No specific revision (document currently at 15) | |
Type | Telechat Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2011-09-02 | |
Requested | 2011-08-19 | |
Authors | Jason Weil , Victor Kuarsingh , Chris Donley , Christopher Liljenstolpe , Marla Azinger | |
I-D last updated | 2011-08-26 | |
Completed reviews |
Genart Last Call review of -??
by Francis Dupont
Genart Last Call review of -?? by Francis Dupont Genart Telechat review of -?? by Francis Dupont Secdir Telechat review of -?? by Yaron Sheffer Tsvdir Last Call review of -?? by Dan Wing |
|
Assignment | Reviewer | Yaron Sheffer |
State | Completed | |
Request | Telechat review on draft-weil-shared-transition-space-request by Security Area Directorate Assigned | |
Completed | 2011-08-26 |
review-weil-shared-transition-space-request-secdir-telechat-sheffer-2011-08-26-00
[Sorry if you receive this message twice. Please respond to this address.] 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 Security considerations are missing and should be added. Details A number of objections were raised on the main IETF mailing list. Not being an expert on IPv6 transition strategies, I will not opine on the value of the proposed address space. However from the point of view of security, the draft needs to be improved. For motivation, the draft refers to a "problem statement" draft, draft-bdgks-arin-shared-transition-space. Looking at the security considerations in draft-bdgks, it is clear that the current document should say much more than "this is not a protocol; there are no security implications," as it currently does. I'm afraid I disagree on both counts: this is indeed a protocol (it defines who is allowed to use these addresses and for what purpose, and it *should* specify how this can be enforced), and there are clear security implications: you don't want people outside the ISP's network (or the ISP's own customers, for that matter) to spoof tunnel termination points. Following up on draft-bdgks, the current document should at least advise on (and better yet, mandate solutions for) "best practices associated with the use of this space, including considerations relating to filtering, routing, etc.". Thanks, Yaron