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

"STARK, BARBARA H" <bs7652@att.com> Tue, 08 January 2019 17:15 UTC

Return-Path: <bs7652@att.com>
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 6EE69130F0B; Tue, 8 Jan 2019 09:15:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 cIAmrMs33CuS; Tue, 8 Jan 2019 09:15:02 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 540E7130F08; Tue, 8 Jan 2019 09:15:02 -0800 (PST)
Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x08H6vm1030116; Tue, 8 Jan 2019 12:14:56 -0500
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0048589.ppops.net-00191d01. with ESMTP id 2pvxy9jeab-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Jan 2019 12:14:56 -0500
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x08HEswA025760; Tue, 8 Jan 2019 12:14:55 -0500
Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x08HEoSR025670; Tue, 8 Jan 2019 12:14:50 -0500
Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 176D040F6CE3; Tue, 8 Jan 2019 17:14:50 +0000 (GMT)
Received: from GAALPA1MSGHUBAD.ITServices.sbc.com (unknown [130.8.218.153]) by zlp30485.vci.att.com (Service) with ESMTPS id 0025340D4417; Tue, 8 Jan 2019 17:14:50 +0000 (GMT)
Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAD.ITServices.sbc.com ([130.8.218.153]) with mapi id 14.03.0415.000; Tue, 8 Jan 2019 12:14:49 -0500
From: "STARK, BARBARA H" <bs7652@att.com>
To: "'Christian Huitema'" <huitema@huitema.net>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
CC: "v6ops@ietf.org" <v6ops@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12
Thread-Index: AQHUplIxzMK3YDjZl0aLw/nLjmGiN6Wj60wAgAAGJ4CAAHv9gP//vwTwgABhWgCAAIqGAIAAVx6w
Date: Tue, 8 Jan 2019 17:14:49 +0000
Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DF88094@GAALPA1MSGUSRBF.ITServices.sbc.com>
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>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.61.166.241]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-08_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=755 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901080139
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/S7mAeHb0jOZfTP6R7SpNjUr6iRA>
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 17:15:03 -0000

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

I agree completely that 802.1X is irrelevant to the types of LANs the CE routers described by this draft are used in, and shouldn't be mentioned in reference to the LAN interfaces of these CE routers.
However, IMO, the security section should be discussing security concerns that arise specifically as a result of the requirements in the draft. Concerns that are independent of these requirements are out of scope. AFAICT, none of the requirements in this draft create/enable new threats or attack vectors related to LAN DHCP spoofing attacks; therefore LAN DHCP spoofing attacks (discussing them and proposing how to address them) are out of scope.
 
> 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.

Intra-LAN routing/bridging/switching/filtering/relaying is out of scope of this draft. Intra-LAN behaviors are not relevant to IPv4aaS. There is no mention of LAN-side DHCPv6 (or DHCPv4) in the draft. All mention of DHCPv6 is WAN interface DHCPv6 client behavior. DHCP(v6) guard isn't a client behavior. I don't like Jordi's suggested text, because (1) as a WAN behavior (which is how most people will interpret it) DHCP guard makes no sense, and (2) as a LAN behavior it's out of scope. 

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

There are no expectations expressed either in this draft or RFC 7084 (which this draft builds upon) that the CE router might be forwarding (or relaying) DHCPv6 packets through the router. RFC 7084 requires the CE router to have its own WAN-facing DHCPv6 client. If it wants to support any sort of LAN-side DHCPv6, it SHOULD have a DHCPv6 server. Nothing about forwarding or relaying. Again, I contend that discussing DHCP Guard in the Security section is out of scope.

Barbara

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