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

["STARK, BARBARA H" <[e-mail]>]

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