> 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. How access networks secure their infrastructure is specific to that access network's architecture. Access network architectures are specified by orgs such as 3GPP, CableLabs, and BBF. In the context of some access network architectures, 802.1X is not the solution that is used, and IETF shouldn't be suggesting they use it. I'm not aware of any that use "DHCPv6 filtering mechanisms" or "DHCP Guard". Most tend to use much more extreme separation of customer traffic. And if an ISP's own managed network elements are compromised, "DHCP Guard" is not the answer -- identifying the compromised network element and removing it from the network is the answer. Which makes this recommendation illogical and inappropriate. Access network architecture is not in scope of this draft. If you really want the paragraph about generic DHCP security issues, I would suggest adding something like this at the end: "Access network architecture for securing DHCP within the access network is out of scope of this document. Securing DHCP in the LAN is also not in scope. DHCP packets MUST NOT be forwarded between LAN and WAN interfaces of an IPv6 Transition CE router." And delete the last 2 paragraphs. Barbara > 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://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIFaQ&c=LFYZ- > o9_HUMeMTSQicvjIg&r=LoGzhC- > 8sc8SY8Tq4vrfog&m=gGwusfSCUjkQieuNQ1I76yNz54321Lz8kiQpqHBBvu0&s > =62NJj2nxHp7lZxf5iEft4SFZ9-mXPvqSAvZvhFbuOu0&e= > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > https://urldefense.proofpoint.com/v2/url?u=http- > 3A__www.theipv6company.com&d=DwIFaQ&c=LFYZ- > o9_HUMeMTSQicvjIg&r=LoGzhC- > 8sc8SY8Tq4vrfog&m=gGwusfSCUjkQieuNQ1I76yNz54321Lz8kiQpqHBBvu0&s > =yRwfzC0UkeyWwWoC5LthWkGDDkAPSoqrNW2MZvFvN_o&e= > 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. > >
