Telechat Review of draft-weil-shared-transition-space-request-

Request Review of draft-weil-shared-transition-space-request
Requested rev. 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
Draft 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
Review review-weil-shared-transition-space-request-secdir-telechat-sheffer-2011-08-26
Review completed: 2011-08-26


[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.


Security considerations are missing and should be added.


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.".