Last Call Review of draft-ietf-6man-oversized-header-chain-08

Request Review of draft-ietf-6man-oversized-header-chain
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-10-16
Requested 2013-10-03
Authors Fernando Gont, Vishwas Manral, Ron Bonica
Draft last updated 2013-10-17
Completed reviews Genart Last Call review of -08 by Peter Yee (diff)
Genart Telechat review of -08 by Peter Yee (diff)
Secdir Last Call review of -08 by Tobias Gondrom (diff)
Assignment Reviewer Tobias Gondrom 
State Completed
Review review-ietf-6man-oversized-header-chain-08-secdir-lc-gondrom-2013-10-17
Reviewed rev. 08 (document currently at 09)
Review result Ready
Review completed: 2013-10-17



        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 ust like any other last
        call comments.

        This ID is Standards Track and and updates RFC 2460 such that
        the first fragment of a packet MUST contain the entire IPv6
        header chain.

        The security considerations section is good. In fact the whole
        draft's objective is to solve a potential security problem with
        super-large IPv6 header chains and enable reliable stateless
        packet filtering for IPv6.


        1. A question, less from a security, but interoperability
        perspective: is there any deplyoment data on any potential
        backwards compatibility issues with current IPv6 deployments?
        Namely are there noteworthy deployments with large IPv6 header
        chains beyond the first fragment currently in deployment? 

        2. section 5 third paragraph: 

        I wonder whether we should be more strict and replace the "MAY"
        with a "SHOULD"? 

        This would make intermediate behavior consistent with the host
        from the previous paragraph and should avoid inconsistencies
        within the network topology? 

        Best regards, Tobias