Skip to main content

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