Re: [secdir] [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Wed, 09 January 2019 10:30 UTC

Return-Path: <prvs=191216c492=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 500D312F1AC; Wed, 9 Jan 2019 02:30:28 -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 jtr_gUOWMrtU; Wed, 9 Jan 2019 02:30:26 -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 A14DD12F1A2; Wed, 9 Jan 2019 02:30:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1547029824; x=1547634624; 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=vT/XEAgZAZVb0i7qY5c5RVHoIgywp4H58PJGELx2mE8=; b=QHj5p8jFlG+ct AKyIPwvDX2RkZKxJXNm8Ff9r5uqmW2QfytlFAg1EDQrGElbSzyEZyZRtowIFORuB XRlRA6ptB6qcs+8oKMbooWbIwJhgKoOSzCFHQruPbvR4CcKrjoWoHSwnbfEJp0J9 WjkOkhkd5qSf3TzhLJAh4DQ9cntJ2Q=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Wed, 09 Jan 2019 11:30:24 +0100
X-Spam-Processed: mail.consulintel.es, Wed, 09 Jan 2019 11:30:22 +0100
Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006103042.msg; Wed, 09 Jan 2019 11:30:20 +0100
X-MDRemoteIP: 2001:470:1f09:495:4069:342c:af81:26bf
X-MDHelo: [10.10.10.140]
X-MDArrival-Date: Wed, 09 Jan 2019 11:30:20 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=191216c492=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
User-Agent: Microsoft-MacOutlook/10.10.5.181209
Date: Wed, 09 Jan 2019 11:30:17 +0100
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Christian Huitema <huitema@huitema.net>, "STARK, BARBARA H" <bs7652@att.com>
CC: "v6ops@ietf.org" <v6ops@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Message-ID: <D1B7D703-9EB1-469C-BC5B-C88E56663D1C@consulintel.es>
Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12
References: <154684244329.17044.2866311660755291596@ietfa.amsl.com> <CD5A6FC1-77A1-42F8-83F6-86581F11E838@consulintel.es> <8E63971A-FEB2-4AB4-BED5-0FEBC8D6949D@consulintel.es> <B0031737-005E-4AF9-9C0C-4A2A5774F73C@huitema.net> <2D09D61DDFA73D4C884805CC7865E6114DF86BB4@GAALPA1MSGUSRBF.ITServices.sbc.com> <F3B1CC63-AF3F-4E13-B03B-FD596113CC44@consulintel.es> <d4b34637-c430-a721-0e8f-93bf6e07dd1a@huitema.net> <2D09D61DDFA73D4C884805CC7865E6114DF88094@GAALPA1MSGUSRBF.ITServices.sbc.com> <E1E98018-4FEC-424D-BFB5-866CC298CF93@consulintel.es> <9674e692-41fd-1ef2-c4dc-9c01d4b49cc0@huitema.net>
In-Reply-To: <9674e692-41fd-1ef2-c4dc-9c01d4b49cc0@huitema.net>
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/NTbPadh9826-aBBAjD6hDR1e8-Q>
Subject: Re: [secdir] [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12
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: Wed, 09 Jan 2019 10:30:28 -0000

Hi Christian,

No, it was not intended to configure the LANs, just the CE.

I think that's clear in the document (abstract, intro), so if you feel that something else need to be included to make sure that is not misunderstood, please, let me know.

In Section 3.2 I've added this, let me know if you think is now clearer:

   Note that this document is only configuring the IPv4aaS in the IPv6
   Transition CE Router itself, and not forwarding such information to
   devices attached to the LANs, so the WAN configuration, availability
   of native IPv4 or IPv4aaS, is transparent for them.

Regarding the Security Section, following your points and Barbara suggestions I've this:


   The IPv6 Transition CE Router must comply with the Security
   Considerations as stated in [RFC7084], as well as those stated by
   each transition mechanism implemented by the IPv6 Transition CE
   Router.

   As described in [RFC8026] and [RFC8415] Security Consideration
   sections, there are generic DHCP security issues, which in the case
   of this document means that malicious nodes may alter the priority of
   the transition mechanisms.

   Access network architecture for securing DHCP within the access
   network is out of scope of this document.  Securing DHCP in the LAN
   is also not in scope.  DHCP packets MUST NOT be forwarded between LAN
   and WAN interfaces of an IPv6 Transition CE router.

Regards,
Jordi
 
 

-----Mensaje original-----
De: ietf <ietf-bounces@ietf.org> en nombre de Christian Huitema <huitema@huitema.net>
Fecha: miércoles, 9 de enero de 2019, 7:14
Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, "STARK, BARBARA H" <bs7652@att.com>
CC: "v6ops@ietf.org" <v6ops@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Asunto: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12

    
    On 1/8/2019 10:38 AM, JORDI PALET MARTINEZ wrote:
    > The security concerns raised *initially* by Christian were related to the use of DHCP for configuring the WAN. At least that was what I understood. Then we continued discussing about the LAN, which I agree with you, is not a requirement on this document.
    
    I may be very confused, because the way I read your draft I assumed that
    the DHCPv6 S46 option was meant to inform the LAN-side devices of the
    available and preferred transition services. From what you are telling
    me, the S46 option is actually provided by the WAN side DHCPv6 server,
    of which the CPE is a client. That would be the preferred way for an ISP
    to configure the customer premise device.
    
    If the DHCPv6 option is only used on the WAN side, then I agree with
    Barbara and you that solutions like DHCP Guard or 802.1x are not
    relevant. There is no need for the proposed paragraph starting with
    "considering that" and ending with "scope of this document".
    
    On the other hand, if I was that much confused, others will be too. I
    might be useful to drop a line in section 3.2 explain in layman terms
    how the S46 option is used.
    
    -- Christian Huitema
    
    
    



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