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@xxxxxxxx> en nombre de Christian Huitema <huitema@xxxxxxxxxxx>
Fecha: martes, 8 de enero de 2019, 6:04
Para: JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@xxxxxxxxxxxxxx>, "STARK, BARBARA H" <bs7652@xxxxxxx>
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
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.
