Re: [dhcwg] Is there scope to address real world issues in RFC8415bis?

[Bernie Volz <[e-mail]>]

The DHCPv6 protocol is a tool. How you or someone else choses to deploy that tool is up to you. There are always tradeoffs in any design … especially in cases where there is a lot of state stored in many different entities (clients, relays or other middleboxes, servers) as that’s always difficult to keep in sync (especially with loosely coupled devices such as those that DHCPv6 usually deals with).

Again, operational advice and documenting tradeoffs can be extremely useful but belongs in a document seperate from the core protocol specification.

Lots of very talented people worked on encryption designs for DHCPv6 but sadly nothing came of it as it is a very difficult problem. In some network architectures it might be less of a problem than others, but no one could come up with a design that would work reasonably well. It’s very easy to say oh let’s encrypt but not so easy when you have to actually design the mechanism.

See for example (in no particular order):

https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/" dir="ltr" width="300">

https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/">Secure DHCPv6 https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/">datatracker.ietf.org

https://datatracker.ietf.org/doc/draft-cui-dhc-dhcpv6-encryption/" rel="nofollow">https://datatracker.ietf.org/doc/draft-cui-dhc-dhcpv6-encryption/

https://datatracker.ietf.org/doc/html/draft-ietf-dhc-secure-dhcpv6-06" dir="ltr" width="300">

https://datatracker.ietf.org/doc/html/draft-ietf-dhc-secure-dhcpv6-06">Secure DHCPv6 Using CGAs https://datatracker.ietf.org/doc/html/draft-ietf-dhc-secure-dhcpv6-06">datatracker.ietf.org

And, I think there was one other document.

The point was that the packets are completely unauthenticated.  The subscriber can share the Client Identifier with others.  At which point the lease is assigned to the wrong subscriber, or to the wrong place in the network.

Yes, this is indeed a problem in several SP technologies and some have used techniques to minimize or at least detect this. As using an alternative client id has other issues, often a technique to validate the “place in the network” is useful. But again, this is a deployment issue and not really a core protocol issue.

- Bernie (from iPad)

On Jul 3, 2023, at 2:56 PM, Alan DeKok <[e-mail]> wrote:

On Jul 1, 2023, at 6:35 AM, Ole Trøan <otroan=[e-mail]> wrote:

IPv6 is designed with some level of address stability in mind. The leased prefix should be tied to the subscriber, not to some entity that changes based on dynamic events in the network.

 The point was that the packets are completely unauthenticated.  The subscriber can share the Client Identifier with others.  At which point the lease is assigned to the wrong subscriber, or to the wrong place in the network.

 ISPs can increase the security of the system by tying subscribers to equipment under the control of the ISP.   e.g. the gateways in between the subscriber and the DHCPv6 server.  This allows an ISP to tie a particular subscriber to a particular "path" through the network.

The only option for the subscribers to protect themselves against ISPs “flash” renumbering customers this way would be to use NPT66 or NAT.

 What about ISPs protecting themselves against subscribers?

As the IETF we have a few options here.

a) not support this in protocols and standards to hope that is enough to discourage this practice

b) Add support for complete ephemeral addressing in ipv6

c) hack and duct tape something so it works for end users that are prohibited from running services in their network.

 Some responses;

For (a), it would be good to have the specifications document how the protocols work, and have at least a paragraph or two about design goals, and recommended operational practices or pitfalls

For (b) and (c), I don't think this is what's being asked for here.

Equipment vendors do things which are apparently against the design principles of DHCPv6.  Since RFC 8415 says nothing on these topics, the only conclusion is that those design principles are incorrect, and that the specification is correct.  As such, this behavior by vendors both follows the specification, and is permitted by it.

 Alan DeKok.

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg