Last Call Review of draft-ietf-v6ops-siit-dc-02
review-ietf-v6ops-siit-dc-02-secdir-lc-gondrom-2015-09-24-00

 

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.








        The draft aims for informational status and describes a
        deployment model for traffic from legacy IPv4-only clients (on
        the Internet) is translated to IPv6 upon reaching the data
        centre. 





        The document appears mostly ok for publication with a series of
        comments. 


        One main question: 

Technically
          this document looks 

to me more like
            standards and not informational as I think we need to
            enforce consistent behaviour and restrictions to ensure
            overall consistency. IMO we need to spell this out more
            explicitly. This is a repeating element, I encountered in
            this review across multiple sections of the document (see
            explanations below). 





        COMMENTS:


        0. 

starting with a
          personal comment:

in general it is nice to move again a
        step closer to a V6, even though these series of baby transition
        steps are quite small. Whether we need this in addition to other
        existing 64 protocols, I leave to the V6ops WG who has much
        better insight into this one than me. 





        1. This document has two strong requirements, that should be
        expressed in 2119 language. 


        1.1. the SIIT algorithm MUST be used. 


        1.2. And the security considerations section MUST be followed. 





        2. Section 7 Security Considerations: 


        2.1. The listed concern is correct. The listed mitigation step
        may work, I would suggest to also add a sentence when you do
        choose this distinct translation prefix, you also must configure
        your FW/GW at the edge to enforce the integrity of that naming
        scheme (e.g. by dropping packets from that prefix if not coming
        from a IPv4) to make sure there is no ambiguity or spoofing. We
        must avoid a blend of translated and untranslated addresses in
        the same prefix if you use the prefix as a marker. 


        2.2. I am not sure you covered all the security concerns in this
        section.  


        2.2.1. e.g. we might want to expand more on the risk that the DC
        does by design not see that we translate this down to V4 at the
        edge and thereby loose some of the capabilities of V6 beyond the
        edge. Therefore the DC may assume a fully V6 conformant client,
        which is not the case. This may lead to the need of further
        filtering or protection mechanisms at the edge. 


        2.2.2. the authors should expand more on architecture
        requirements not to put two of these translators in sequence
        (see possibly conflicts with 2.2.3. the authors should expand
        more on restrictions of putting this in a mixed environment with
        NAT64





        3. section "4.4. Choice of Translation Prefix"


        - states: "Either a Network-Specific Prefix (NSP) from the
        provider's own IPv6 address space or the IANA-allocated
        Well-Known Prefix 64:ff9b::/96  (WKP) may be used."


        I think this needs to be a MUST instead of the "may". Also I do
        not like the ambiguity of prefixes here. We need to make it
        clear that this translastion MUST be consistent across all edges
        to the DC. 





        4. section 4.5. routing considerations: 


        - do we need to specify that all alternate BRs must use the same
        algorithm and all MUST be able to support SIIT-DC? 





        5. section 4.6: 


        we say "This should be understood to include all servers,"


        I am not sure this is only a "should". From a lingual
        perspective it might be meaning that it "it should be understood
        that it requires..." but as the word "required" is not used, it
        is a bit unclear to me, whether that is also understood by the
        author/WG for this protocol. 





        6. section 4.8.: 


        we use "To facilitate reliable delivery of such ICMPv6 errors n
        SIIT-DC operator SHOULD implement the recommendations in
        [RFC6791] in the BRs." Is there a security consideration on the
        impact what happens if RFC6791 is not followed and ICMPv6 errors
        are dropped? What would be the security implications of loosing
        not transmitting these messages? 





        7. section 4.9. "MTU and Fragmentation": 


        it is good that we spell out the series of key differences
        between IPv4 and IPv6 relating to packet sizes and fragmentation
        that one needs to consider when deploying SIIT-DC. I am not sure
        a "should" is sufficient here. Furthermore, it would be good to
        consider whether we need to specify and mandate the specific
        behaviour when encountering these limitations to avoid
        inconsistent behaviour from the BR if these parameters are
        encountered and this might be exploited as an attack vector. 





        Thank you and best regards.





        Tobias