Re: [secdir] [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 13 December 2018 22:09 UTC

Return-Path: <prvs=1885a872f7=jordi.palet@consulintel.es>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A6A130EAB; Thu, 13 Dec 2018 14:09:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 5_UocSz880fb; Thu, 13 Dec 2018 14:09:18 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E740F130EA9; Thu, 13 Dec 2018 14:09:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1544738953; x=1545343753; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=wr+XANuANecS0GYlO+Omfz5q8NiilK8Ke9B377eVZYs=; b=OxFrD8td9bD3R l9CtefcdORS9X8pStsNMOf0y8zQV+CK2PnsOEJd6hCUiA0C8FKy5Odh7IKcwz3vF vRmWpjXOh4hBJdPe0Jn1OR5e/65vw5cn7dkfJ+dCRBShBShkAQs/93R/EmDdn18T gRH6kchQsb3BzE8OxrhUZ32Dh/WhHg=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Thu, 13 Dec 2018 23:09:13 +0100
X-Spam-Processed: mail.consulintel.es, Thu, 13 Dec 2018 23:09:12 +0100
Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006063193.msg; Thu, 13 Dec 2018 23:09:12 +0100
X-MDRemoteIP: 2001:470:1f09:495:a811:1373:c444:4be5
X-MDHelo: [10.10.10.130]
X-MDArrival-Date: Thu, 13 Dec 2018 23:09:12 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1885a872f7=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
User-Agent: Microsoft-MacOutlook/10.10.5.181209
Date: Thu, 13 Dec 2018 23:09:09 +0100
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Christian Huitema <huitema@huitema.net>, <secdir@ietf.org>
CC: <v6ops@ietf.org>, <ietf@ietf.org>, <draft-ietf-v6ops-transition-ipv4aas.all@ietf.org>
Message-ID: <5BF30E2E-4B57-415E-8D8D-6C6815B604FF@consulintel.es>
Thread-Topic: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11
References: <154473417654.32125.9104927217788947044@ietfa.amsl.com>
In-Reply-To: <154473417654.32125.9104927217788947044@ietfa.amsl.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/_X7M7hoUF7d9nq1haIoalc8SbiI>
Subject: Re: [secdir] [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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, 13 Dec 2018 22:09:21 -0000

Hi Christian,

Thanks a lot for your review.

Please see below in-line.

I'm working in a new version according to the comments got from the ops review as well, so will be able to integrate yours very quickly.

Regards,
Jordi
 
 

-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de Christian Huitema <huitema@huitema.net>
Fecha: jueves, 13 de diciembre de 2018, 21:50
Para: <secdir@ietf.org>
CC: <v6ops@ietf.org>rg>, <ietf@ietf.org>rg>, <draft-ietf-v6ops-transition-ipv4aas.all@ietf.org>
Asunto: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11

    Reviewer: Christian Huitema
    Review result: Has Issues
    
    I have reviewed draft-ietf-v6ops-transition-ipv4aas-11 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 summary of the review is "ready with issue".
    
    The document describes solution for providing "IPv4 as a service", i.e.
    provision of IPv4 as a service over an IPv6 only network.
    It calls this support "transition as a service".
    
    For various reasons, IETF working groups have standardized not just one but
    five different mechanisms for providing this transition: 464XLAT [RFC6877],
    Dual-Stack Lite [RFC6333], Lightweight 4over6 (lw4o6) [RFC7596],
    MAP-E [RFC7597], and MAP-T [RFC7599]. (I am sure that Monty Python could have
    produced a nice sketch about that.) The purpose of the draft is to
    state how home routers (a.k.a. customer premise equipment, CPE) should
    inform local devices about which of the mechanisms are available, which
    should be preferred, and what parameters should be used when deploying
    the chosen services. This is done using the DHCPv6 "S46" option
    specified in RFC 8026.
    
    The draft also makes specific recommendation regarding the use of the UPnP and
    PCP services, by requiring specific error codes when a requested port mapping 
    is not available through the specified transition technology.
    
    The security section briefly points to the "Basic Requirements for IPv6
    Customer Edge Routers" specified in RFC 7084, and to the security
    section of each of the RFC describing the security technologies, and implicitly
    argues that there are no other security issues. I think that is insufficient.
    
    The draft introduces a reliance on the DHCPv6 "S46" option for assessing the
    relative priority of different transition technologies. An attacker could spoof
    the DHCPv6 response, and direct client traffic to a different technology than
    selected by the service provider. This could be used, for example, to capture
    IPv4 traffic in an IPv6 network and send it to a route chosen by the attacker.
    The attack might also be used in a dual stack network that does not support
    any transition technology. I don't understand how this attack is mitigated.

Not sure if you will suggest here that we should say something about the security considerations already mention in RFC8026. In general all those are generic DHCPv6 security considerations I think.
    
    Nits:
    
    The introduction uses the acronym WAN without spelling out "Wide Area Network". 
    Also, WAN is used as substitute for local Internet Service Provider network. We could
    debate whether such networks are always "wide area", by opposition to say
    "metropolitan" or "regional". This is the same convention used in RFC 7084 that
    this document updates. It is arguably defined by reference, but spelling it out
    would be nice.
 
Will do.

   
    The comparison with RFC7084 section includes a mangled sentence: 
    
       This document doesn't include support for 6rd ([RFC5969]), because as
       in an IPv6-in-IPv4 tunneling.

Typo, sorry the correct sentence was:
       This document doesn't include support for 6rd ([RFC5969]), because is
       an IPv6-in-IPv4 tunneling.
    
    Please rephrase. Please also rephrase the next sentence, for similar reasons:
    
       Regarding DS-LITE [RFC6333], this document includes slightly
       different requirements, because the PCP ([RFC6887]) support and the
       prioritization of the transition mechanisms, including dual-stack.

I think it is much clear this way:

       Regarding DS-LITE [RFC6333], this document includes slightly
       different requirements, related to the support of PCP ([RFC6887]),
       IGD-PCP IWF [RFC6970] and the prioritization of the transition 
       mechanisms, including dual-stack.    
    
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.