[secdir] secdir review of draft-ietf-v6ops-siit-dc-02

Tobias Gondrom <tobias.gondrom@gondrom.org> Thu, 24 September 2015 10:45 UTC

Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3941A0371; Thu, 24 Sep 2015 03:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.064
X-Spam-Level:
X-Spam-Status: No, score=-96.064 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=1.951, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjbfW0f04t5w; Thu, 24 Sep 2015 03:45:36 -0700 (PDT)
Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF991A0379; Thu, 24 Sep 2015 03:45:35 -0700 (PDT)
Received: from [192.168.43.211] (ip-109-40-100-106.web.vodafone.de [109.40.100.106]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 6E4FD63ABC; Thu, 24 Sep 2015 12:45:31 +0200 (CEST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=kjk1JtO8Ao9EvQFARkO9RXKeZm2IywW+NhNMhqMMY4mO1RHCaJwghZLYhhGPqTxDHrFnKjO527sakS78oEC3FK20H5Q0ebojMfRrkx5BB42/Z1hwcrk7abdajbYmxA9YYzVB6IQsjhFgBxwAiUp19+T08ePVzqrkkYGfqnZWwlk=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type;
Message-ID: <5603D448.3060701@gondrom.org>
Date: Thu, 24 Sep 2015 03:45:28 -0700
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-v6ops-siit-dc.all@tools.ietf.org
Content-Type: multipart/alternative; boundary="------------040602090704080503050005"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/QWXweXazL-sCW5xoOPiuJbWBY7U>
Cc: tore@redpill-linpro.com
Subject: [secdir] secdir review of draft-ietf-v6ops-siit-dc-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Sep 2015 10:45:38 -0000

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