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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Tue, 08 January 2019 08:44 UTC

Return-Path: <prvs=1911ba6fdf=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 14BF51310F3; Tue, 8 Jan 2019 00:44:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] 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 ZWIcThuNzdrT; Tue, 8 Jan 2019 00:44: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 8E4C3131102; Tue, 8 Jan 2019 00:44:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1546937054; x=1547541854; 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=WpQTsSbxqLYLfXsxPD/b57tv5OkQwTE1wEfxivSAIkI=; b=jzgTh/cxbVE37 9OlpWTF9RzqivC8y2keW/jgiCaDU6Px9GtLTPT9rMmFckz6f+KKOCx9VTfpKd0fJ 22XwF3/5KwI7FzVCy1QjOODvP/ZLNJYJ4NTuJO6jRLhhQs/2gBt6AH90fy1zX+hd B+YhjfK9t6tprxSSNUFXOPNcQ12tJ4=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Tue, 08 Jan 2019 09:44:14 +0100
X-Spam-Processed: mail.consulintel.es, Tue, 08 Jan 2019 09:44:14 +0100
Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006101437.msg; Tue, 08 Jan 2019 09:44:12 +0100
X-MDRemoteIP: 2001:470:1f09:495:78d5:b4a1:adaa:b67c
X-MDHelo: [10.10.10.140]
X-MDArrival-Date: Tue, 08 Jan 2019 09:44:12 +0100
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1911ba6fdf=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
User-Agent: Microsoft-MacOutlook/10.10.5.181209
Date: Tue, 08 Jan 2019 09:44:11 +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: <B28B619E-3A98-4567-8169-ADCE2911F9CD@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>
In-Reply-To: <d4b34637-c430-a721-0e8f-93bf6e07dd1a@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/7gHlJKdIHvalFeVrm2KxLN6fadY>
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: Tue, 08 Jan 2019 08:44:21 -0000

Hi Christian,

While I'm sympathetic with all what you said, this document is not adding/changing anything regarding the LAN-side configuration related to DHCP, and from that perspective, we refer to what is already required by RFC7084, which in turn calls to RFC6092.

If I recall correctly, RFC6092 doesn't say anything about DHCP/RA security.

I see SMEs with hundreds of employees, using this kind of routers connected to 600 Mbps FTTH symmetric links (Spain, but I'm sure is the same case in many other countries). However, in those cases, the router is only used a "pure router", and there is a server(s) providing DHCP, NAT, firewall, etc., switches (which in many cases do DHCP-guard features as well as RA-Guard).

The reason for it, is that those organizations don't have a "critical" need to connect to internet (if it fails a few hours is not a problem, they don't host internal services to be accessed from Internet), or even it is much cheaper to have 2 or 3 of those links (in Spain the cost is about 40 Euros per month, including flat rate VoIP for national calls, any kind of failure needs to be fixed in a maximum of 24 hours, by law, while typically is less than 8 hours) for backup/load balancing.

If they choose a "corporate" link type, they will get a "business" router, the link is the same (connecting to the same access/core infrastructure), just they get a "promise" of a better SLA, but then they will need to pay 400 Euros/month for the link.

Anyway, I agree with the suggested changes, as it doesn't harm if we don't explicitly say in the security section that the text is related to the LAN or WAN side. Is up to the implementor in this case, to decide if they want to offer a "better" CE firmware supporting those additional features.

Regards,
Jordi
 
 

-----Mensaje original-----
De: ietf <ietf-bounces@ietf.org>; en nombre de Christian Huitema <huitema@huitema.net>;
Fecha: martes, 8 de enero de 2019, 6:04
Para: JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>;, "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/7/2019 11:58 AM, JORDI PALET MARTINEZ wrote:
    > Hi Barbara,
    >
    > I agree with your regarding the WPA, not sure to understand the point from Christian.
    >
    > If a local device is compromised, that happens in the LANs and this will only affect the CE, if the "virus" or "bot" or whatever is able to compromise the CE configuration and then replace some of the settings done by the provisioning system.
    >
    > This is something that may happen regardless of using DHCP in the WAN or other protocols.
    >
    > I recall having seen some TR-069 mechanism (maybe it was proprietary) to provide something related to access control security, but if it is not standard, I will remove it. Let's see if someone in the list can provide some info and I will also try to recall what was in the case I've in mind.
    
    Maybe I was not clear. I am not overly concerned with what happens on
    the WAN side -- I assume that the ISP deploying customer premise devices
    will find a way to provision them securely. I am concerned that using
    DHCPv6 to provision networking parameters on the local hosts exposes
    these hosts to generic DHCP spoofing attacks. To mount the DHCP spoofing
    attacks, the attacker will need to either gain connectivity to the local
    network, or gain controlled of a local device. Access control protocols
    like 802.1x will prevent unauthorized devices from connecting to the
    local network; they will not close the second avenue of attack,
    something that solutions like DHCP guard would do.
    
    The local router can filter which packets are relayed between Wi-Fi
    devices, and can filter out spoofed DHCP packets. That's reasonably easy
    to deploy in small networks, where the only authorized DHCP server is
    located on the router itself. Of course, the current document is not
    meant as a general home router requirement draft -- it just specifies
    the narrow problem of how these routers should facilitate deployment of
    IPv4 as a service. I do like Jordi's succession to refer to DHCP Guard
    as a potential mitigation of DHCPv6 issues, because it can be deployed
    simply and it would thwart a series of potential attacks.
    
    I am less enthusiastic about 802.1x, because as I said above it
    addresses a fraction of the problem, but not the whole problem. Standard
    deployment of 802.1x requires an authentication server, which currently
    does not come with small routers. It also requires management of this
    authentication server, which is a tall order in these small networks.
    There have been attempts to define a simpler profile of 802.1x, in which
    all users have the same ID and the same password -- such as what is used
    in the IETF Wi-Fi networks. This does improve somewhat over the
    residential version of WPA, in which all users share the same "Wi-Fi
    password", because it provides better isolation between users. But I
    would have a hard time recommending 802.1x deployment in residential
    networks "because of DHCPv6 security".
    
    While I do like the "DHCP Guard" class of solutions, I am also concerned
    that the DHCP Guard concept is only defined by the commercial literature
    of some vendors -- and the same goes for DHCP Snooping, which could have
    a variety of meanings. If you want to use that term, then you should add
    a reference to the paper where this is defined. Or you could use neutral
    language, like:
    
      Considering that, networks using DHCPv6, depending on their specific
      topologies, should consider using access control mechanisms such as
      those based on IEEE-802.1X, and DHCPv6 filtering mechanisms designed to
      prevent forwarding of spoofed DHCPv6 packets through the router, often
      referred to as "DHCP Guard."
    
    I am also skeptical of the mention of "SME" in the last paragraph, in
    "deployment of IPv4aaS in residential, SOHO and SME networks". The
    definition of what is a small or medium enterprise varies by countries.
    In the European Union, it is up to 250 employees. In the US, it is
    defined by revenues and employees limit, typically fewer than 500
    employees. In other part of the world, it can be fewer than 50
    employees, or maybe it is just defined by a limit on revenues. In any
    case, I would personally be reluctant to deploy simple devices like
    described in the draft in a network with 100 to 200 people, let alone
    500. That would be pushing luck a bit too far.
    
    The introduction of the draft says "This document defines IPv4 service
    continuity features over an IPv6-only network, for a residential or
    small-office router..." I would suggest using exactly the same language,
    as in:
    
      As stated in the introduction, this document addresses deployment of
      IPv4aaS in residential or small-office networks.  Deployment in more
      challenging environments would require additional security analysis.
    
    -- 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.