Hi Barbara,
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 guess the right way to approach this will be to update RFC6092 with new minimum security requirements, but this is out of the scope of this thread.
This is what I'm proposing, making sure that we are speaking about the DHCPv6 requirements from this document, but at the same time remembering that the LAN side is also important (but not in the scope of this document):
8. Security Considerations
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.
Considering that, networks using DHCPv6 as indicated in this document,
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 to the IPv6 Transition CE, often
referred to as "DHCP Guard". Those can be used as well, in the
LAN side, but this is out of the scope of this document.
As stated in the introduction, this document addresses deployment of
IPv4aaS in residential or SOHO networks. Deployment in more
challenging environments would require additional security analysis.
Regards,
Jordi
-----Mensaje original-----
De: v6ops <v6ops-bounces@xxxxxxxx> en nombre de "STARK, BARBARA H" <bs7652@xxxxxxx>
Fecha: martes, 8 de enero de 2019, 18:16
Para: 'Christian Huitema' <huitema@xxxxxxxxxxx>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@xxxxxxxxxxxxxx>
CC: "v6ops@xxxxxxxx" <v6ops@xxxxxxxx>, "ietf@xxxxxxxx" <ietf@xxxxxxxx>, "secdir@xxxxxxxx" <secdir@xxxxxxxx>
Asunto: Re: [v6ops] Secdir telechat review of draft-ietf-v6ops-transition-ipv4aas-12
> 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
>
>
_______________________________________________
v6ops mailing list
v6ops@xxxxxxxx
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.
