| Message ID | CY4PR11MB1559E56DDFA1A947FD1C778BCC200@CY4PR11MB1559.namprd11.prod.outlook.com |
|---|---|
| State | Rejected |
| Delegated to: | Hans Dedecker |
| Headers | show |
Eric Luehrsen <ericluehrsen@hotmail.com> writes: > IP6 SLAAC plus privacy is common. DHCPv6 should be able to provide > the same funciton. This way central IT can maintain integrity and > traceability. However, individual machines will not be easily > placed into a pattern over time by external snooping. This looks wrong. The "NA" in IA_NA means "non-temporary addresses". You cannot change that without breaking client expectations. You should implement IA_TA if you want DHCPv6 privacy addresses. See section 12 of RFC 3315 (which is referred to by RFC 4941). Bjørn
Eric Luehrsen <ericluehrsen@hotmail.com> writes: > It appears many other severs and clients dont implement IA_TA. Its a lost option. Sure. Very few want this feature. We must however assume that those who do want it will implement it. > It should not break "expectations" as this an central administrative > option. A client requesting an IA_NA expects a non-temporary address. > If central IT doesnt want user base devices to be permanently reachable > or traceable, then that is their authority to choose. Definitely. They can easily achieve this by not providing any IA_NA adresses. > But on the flip side, central IT doesnt want the insanity of SLAAC > Privacy all over their network. Consider a fortune 500 company or > university with accountibilty and traceability in legal or internal > policy requirements. > > RFC are so namef for a reason and a good working model can change them. OK, I think you just explained your level of understanding. Thanks Bjørn
On 03/10/2017 09:09 AM, Bjørn Mork wrote: > Eric Luehrsen <ericluehrsen@hotmail.com> writes: >> It appears many other severs and clients dont implement IA_TA. Its a lost option. > Sure. Very few want this feature. We must however assume that those > who do want it will implement it. We must however assume nothing. We may assume something while patiently waiting for information so we can progress on an idea. >> It should not break "expectations" as this an central administrative >> option. > A client requesting an IA_NA expects a non-temporary address. > I hate being "legislative" about engineering, but it looks like this is headed that way, so I'll bite. First in all engineering requirements you must define your terms. "non-temporary" does not mean "permanent" and it appears it is carefully avoided as such. In fact the only implied definition through the chain of RFC is "non-temporary" is just not the same as "temporary." "temporary" could be summarized as having the potential for even per connection or per application duration. With that "non-temporary" can reasonably be defined by the local site administration as a work shift (8hrs) or something like that. This means "non-temporary" is a policy decision by the organization management ("oh no" software engineers cry, "not management"). If management wants DHCPv6 to provide a single address per user level machine, then that's their decision to make. If management wants that each work day or each work shift enumerates all user level machines differently, then that's their decision to make. DHCPv6 IA_NA then is the one and only address that your issued device gets, and it is different each work day. Static servers may have predefined host assignments, which I only mention for completeness. >> If central IT doesnt want user base devices to be permanently reachable >> or traceable, then that is their authority to choose. > Definitely. They can easily achieve this by not providing any IA_NA > adresses. How is that an answer for above management attempting to implement a particular policy? DHCPv6 IA_TA is not option for (any?) clients. By your implied definition, a client device would get also an IA_NA that is "more lasting." It may try to use it, but management doesn't want that. DHCPv6 without something else leaves devices easily profiled from external snooping. It's not MAC but not good either. SLAAC exposes the MAC publicly. SLAAC+privacy is internally difficult to trace, so likely fail accountability. SLAAC w/ RA rolling hash isn't any more implemented than IA_TA. >> But on the flip side, central IT doesnt want the insanity of SLAAC >> Privacy all over their network. Consider a fortune 500 company or >> university with accountibilty and traceability in legal or internal >> policy requirements. >> >> RFC are so namef for a reason and a good working model can change them. > OK, I think you just explained your level of understanding. Thanks I'll pretend that it doesn't mean how it reads. - Eric
> Op 11 mrt. 2017, om 06:09 heeft Eric Luehrsen <ericluehrsen@hotmail.com> het volgende geschreven: > > On 03/10/2017 09:09 AM, Bjørn Mork wrote: >> Eric Luehrsen <ericluehrsen@hotmail.com> writes: >>> It appears many other severs and clients dont implement IA_TA. Its a lost option. >> Sure. Very few want this feature. We must however assume that those >> who do want it will implement it. > We must however assume nothing. We may assume something while patiently > waiting for information so we can progress on an idea. >>> It should not break "expectations" as this an central administrative >>> option. >> A client requesting an IA_NA expects a non-temporary address. >> > I hate being "legislative" about engineering, but it looks like this is > headed that way, so I'll bite. First in all engineering requirements you > must define your terms. "non-temporary" does not mean "permanent" and it > appears it is carefully avoided as such. In fact the only implied > definition through the chain of RFC is "non-temporary" is just not the > same as "temporary." "temporary" could be summarized as having the > potential for even per connection or per application duration. With that > "non-temporary" can reasonably be defined by the local site > administration as a work shift (8hrs) or something like that. rfc3315#section-12 refers to rfc3041 for the definition of temporary addresses. The usage of temporary addresses by rfc3041 (Privacy Extensions for Stateless Address Autoconfiguration in IPv6) seems to imply, a contrario, that non-temporary addresses are _not_ to be used for the privacy purposes. Strictly logically this implication is incorrect, but still it very much aligns with understandable and reasonable expectations. Anyway, non-temporary isn’t the same as permanent. > This means "non-temporary" is a policy decision by the organization > management ("oh no" software engineers cry, "not management"). If > management wants DHCPv6 to provide a single address per user level > machine, then that's their decision to make. If management wants that > each work day or each work shift enumerates all user level machines > differently, then that's their decision to make. DHCPv6 IA_NA then is > the one and only address that your issued device gets, and it is > different each work day. Static servers may have predefined host > assignments, which I only mention for completeness. >>> If central IT doesnt want user base devices to be permanently reachable >>> or traceable, then that is their authority to choose. >> Definitely. They can easily achieve this by not providing any IA_NA >> adresses. > How is that an answer for above management attempting to implement a > particular policy? DHCPv6 IA_TA is not option for (any?) clients. By > your implied definition, a client device would get also an IA_NA that is > "more lasting." It may try to use it, but management doesn't want that. > DHCPv6 without something else leaves devices easily profiled from > external snooping. It's not MAC but not good either. SLAAC exposes the > MAC publicly. SLAAC+privacy is internally difficult to trace, so likely > fail accountability. SLAAC w/ RA rolling hash isn't any more implemented > than IA_TA. (mind you, I am not an expert and the following could be utter nonsense). Given these use-cases (IAs per work shift etc), why couldn’t these be fulfilled with IA_TA ? Both types of associations are within control of the server and hence of whatever management policy, or would the use of IA_NA be necessitated because clients tend not request these ? If so, then use of IA_TA is a client policy, and support of those by the DHCPv6 server would be nice. Where the intended enhancement of privacy is a server policy and the client does not request IA_TA, use of IA_NA for this purpose seems alright since whatever address is provided is within the realm of the server for whatever policy it implements thereby. >> >>> But on the flip side, central IT doesnt want the insanity of SLAAC >>> Privacy all over their network. Consider a fortune 500 company or >>> university with accountibilty and traceability in legal or internal >>> policy requirements. >>> >>> RFC are so namef for a reason and a good working model can change them. >> OK, I think you just explained your level of understanding. Thanks > I'll pretend that it doesn't mean how it reads. I’ve read the sentence a few times over and still cannot make out what would be meant be it. Still given the effort made to sensibly discus this subject one would be wise to read it positively. (credo: when a positive explanation exists that is as reasonable as any other, pick the positive one) > > - Eric -- Paul > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev
Small addition (the following may be non-obvious to those not involved in this discussion). Just saw that A_TA does not have renewal (T1) or rebinding (T2) fields and for that reason cannot suit a use-case like a IA just for a work shift.
Paul Oranje <por@xs4all.nl> writes: > Small addition (the following may be non-obvious to those not involved > in this discussion). Just saw that A_TA does not have renewal (T1) or > rebinding (T2) fields and for that reason cannot suit a use-case like > a IA just for a work shift. RFC 3315 section 22.5: An IA_TA option does not include values for T1 and T2. A client MAY request that the lifetimes on temporary addresses be extended by including the addresses in a IA_TA option sent in a Renew or Rebind message to a server. For example, a client would request an extension on the lifetime of a temporary address to allow an application to continue to use an established TCP connection. But I'm not convinced temporary addresses fits that use case. In any case, there are existing client implementations of IA_TA (for example ISC dhclient and dibbler) and RFC7721 stable IIDs (for example Linux kernel and NetworkManager). Bjørn
> Op 11 mrt. 2017, om 14:09 heeft Bjørn Mork <bjorn@mork.no> het volgende geschreven: > > Paul Oranje <por@xs4all.nl> writes: > >> Small addition (the following may be non-obvious to those not involved >> in this discussion). Just saw that A_TA does not have renewal (T1) or >> rebinding (T2) fields and for that reason cannot suit a use-case like >> a IA just for a work shift. > > RFC 3315 section 22.5: > > An IA_TA option does not include values for T1 and T2. A client MAY > request that the lifetimes on temporary addresses be extended by > including the addresses in a IA_TA option sent in a Renew or Rebind > message to a server. For example, a client would request an > extension on the lifetime of a temporary address to allow an > application to continue to use an established TCP connection. > > > But I'm not convinced temporary addresses fits that use case. The use-case that Eric gave as an example - as I understood it - concerns policies that are enforced at the server side; at the client site “management" cannot enforce anything. > In any case, there are existing client implementations of IA_TA (for > example ISC dhclient and dibbler) and RFC7721 stable IIDs (for example > Linux kernel and NetworkManager). Maybe you can create a patch that would implement IA_TA in odhcpd, if that isn’t implemented yet (I do not know, have a look at the code). That would satisfy another use case. > > > Bjørn > > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev
This discussion has really put some requirements and restrictions on what I am trying to implement. I like that. Excuse my stream of consciousness writing style, if you question "what? .. crazy?" then its likely my fault for not editing well. On 03/11/2017 11:39 AM, Paul Oranje wrote: >> RFC 3315 section 22.5: >> >> An IA_TA option does not include values for T1 and T2..... > The use-case that Eric gave as an example - as I understood it - concerns policies that are enforced at the server side; at the client site “management" cannot enforce anything. > Simply, a rational management desire would be to have similar or "transparent" system of policies between IP4 and IP6. They have decades of "Oh! ####!" lessons learned including tools built around DHCPv4. They want evolution not revolution in the change over. During an hypothetical IP6 roll out plan meeting ... The potential for IP6 to profile a network externally is considered and the emotional response is "unsettling" at best. The potential for loss of control with SLAAC is equally emotional. Hopefully someone well spoken and well respected explains NAT is not security, or storm clouds form. Desire: one global IP6 per (virtual) machine just like was had with IP4. Desire: external network obscurity just like was had with IP4. Desire: full traceability and accountability for all intranet and internet connections. Desire: time and point of first connection logs as mobile devices attach. Desire: not require extra steps or tools for general employees to "work around" issues. Desire: IT policy/training/manuals don't need to change in grand structure (only change specifics in implementation) Desire: DUID or Client-ID or MAC is an "asset tag" and not modified session to session. DHCPv6 IA_NA which is NOT simply a fixed hash of DUID but also a random function over moderate periods of time would be within standard and meet these desires. Within "accountability and traceability" a limit to address roll over frequency creates another rational definition of "non-temporary." >> In any case, there are existing client implementations of IA_TA (for >> example ISC dhclient and dibbler) and RFC7721 stable IIDs (for example >> Linux kernel and NetworkManager). > Maybe you can create a patch that would implement IA_TA in odhcpd, if that isn’t implemented yet (I do not know, have a look at the code). > That would satisfy another use case. This could/should also be done, but many as-purchased devices just don't handle IA_TA (well). Okay, more generically IP6 isn't often handled (well). It will be hard to test robustly. IA_TA can deliver a plurality of addresses for machine/connection obscurity. "How many?" becomes a compatibility and complexity issue as one example. Hurdle: If IT is conservative about in house modification and wants to deploy user-end equipment as-purchased, then this could limit their supplier options and the buyers negotiation leverage. Modifying and maintaining infrastructure is an IT job. Supporting all the daily user issues is often part of the service contract with the user equipment provider. If we want providers support, then use the equipment as-purchased or within boundaries as specified in the contract.
Patchwork: Reject Patch. It needs improvement. The time base for the address needs more stable regulation just for one. - Eric
> Op 12 mrt. 2017, om 18:31 heeft Eric Luehrsen <ericluehrsen@hotmail.com> het volgende geschreven: > > This discussion has really put some requirements and restrictions on > what I am trying to implement. I like that. Excuse my stream of > consciousness writing style, if you question "what? .. crazy?" then its > likely my fault for not editing well. > > On 03/11/2017 11:39 AM, Paul Oranje wrote: >>> RFC 3315 section 22.5: >>> >>> An IA_TA option does not include values for T1 and T2..... >> The use-case that Eric gave as an example - as I understood it - concerns policies that are enforced at the server side; at the client site “management" cannot enforce anything. >> > Simply, a rational management desire would be to have similar or > "transparent" system of policies between IP4 and IP6. They have decades > of "Oh! ####!" lessons learned including tools built around DHCPv4. They > want evolution not revolution in the change over. > > During an hypothetical IP6 roll out plan meeting ... The potential for > IP6 to profile a network externally is considered and the emotional > response is "unsettling" at best. The potential for loss of control with > SLAAC is equally emotional. Hopefully someone well spoken and well > respected explains NAT is not security, or storm clouds form. > > Desire: one global IP6 per (virtual) machine just like was had with IP4. > Desire: external network obscurity just like was had with IP4. > Desire: full traceability and accountability for all intranet and > internet connections. > Desire: time and point of first connection logs as mobile devices attach. > Desire: not require extra steps or tools for general employees to "work > around" issues. > Desire: IT policy/training/manuals don't need to change in grand > structure (only change specifics in implementation) > Desire: DUID or Client-ID or MAC is an "asset tag" and not modified > session to session. > > DHCPv6 IA_NA which is NOT simply a fixed hash of DUID but also a random > function over moderate periods of time would be within standard and meet > these desires. Within "accountability and traceability" a limit to > address roll over frequency creates another rational definition of > "non-temporary." > >>> In any case, there are existing client implementations of IA_TA (for >>> example ISC dhclient and dibbler) and RFC7721 stable IIDs (for example >>> Linux kernel and NetworkManager). >> Maybe you can create a patch that would implement IA_TA in odhcpd, if that isn’t implemented yet (I do not know, have a look at the code). >> That would satisfy another use case. > This could/should also be done, but many as-purchased devices just don't > handle IA_TA (well). Okay, more generically IP6 isn't often handled > (well). It will be hard to test robustly. IA_TA can deliver a plurality > of addresses for machine/connection obscurity. "How many?" becomes a > compatibility and complexity issue as one example. What policies the server could implement while serving a requested IA_TA ? (In case the server has to deal with a (rare) client that does requests that). I ask this question since the nature of this IA probably restricts what policies one can implement. > > Hurdle: If IT is conservative about in house modification and wants to > deploy user-end equipment as-purchased, then this could limit their > supplier options and the buyers negotiation leverage. Modifying and > maintaining infrastructure is an IT job. Supporting all the daily user > issues is often part of the service contract with the user equipment > provider. If we want providers support, then use the equipment > as-purchased or within boundaries as specified in the contract. > > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev
diff --git a/README b/README index ebb2d99..c382852 100644 --- a/README +++ b/README @@ -86,6 +86,8 @@ dhcpv4 string disabled DHCPv4 service ndp string disabled Neighbor Discovery Proxy [disabled|relay|hybrid] +dhcpv6_privacy bool 0 32-bit random HOSTID + for DHCPv6 dynamicdhcp bool 1 dynamically create leases for DHCPv4 and DHCPv6 router list <local address> Routers to announce diff --git a/src/config.c b/src/config.c index 689d4ce..6c196e0 100644 --- a/src/config.c +++ b/src/config.c @@ -40,6 +40,7 @@ enum { IFACE_ATTR_DOMAIN, IFACE_ATTR_FILTER_CLASS, IFACE_ATTR_DHCPV6_RAW, + IFACE_ATTR_DHCPV6_PRIVACY, IFACE_ATTR_RA_DEFAULT, IFACE_ATTR_RA_MANAGEMENT, IFACE_ATTR_RA_OFFLINK, @@ -76,6 +77,7 @@ static const struct blobmsg_policy iface_attrs[IFACE_ATTR_MAX] = { [IFACE_ATTR_DOMAIN] = { .name = "domain", .type = BLOBMSG_TYPE_ARRAY }, [IFACE_ATTR_FILTER_CLASS] = { .name = "filter_class", .type = BLOBMSG_TYPE_STRING }, [IFACE_ATTR_DHCPV6_RAW] = { .name = "dhcpv6_raw", .type = BLOBMSG_TYPE_STRING }, + [IFACE_ATTR_DHCPV6_PRIVACY] = { .name = "dhcpv6_privacy", .type = BLOBMSG_TYPE_BOOL }, [IFACE_ATTR_PD_MANAGER] = { .name = "pd_manager", .type = BLOBMSG_TYPE_STRING }, [IFACE_ATTR_PD_CER] = { .name = "pd_cer", .type = BLOBMSG_TYPE_STRING }, [IFACE_ATTR_RA_DEFAULT] = { .name = "ra_default", .type = BLOBMSG_TYPE_INT32 }, @@ -195,6 +197,7 @@ static void set_interface_defaults(struct interface *iface) iface->managed = 1; iface->learn_routes = 1; iface->dhcpv4_leasetime = 43200; + iface->dhcpv6_privacy = 0; iface->ra_maxinterval = 600; iface->ra_mininterval = iface->ra_maxinterval/3; iface->ra_lifetime = -1; @@ -441,6 +444,10 @@ int config_parse_interface(void *data, size_t len, const char *name, bool overwr iface->dhcpv4_end.s_addr = htonl( ntohl(iface->dhcpv4_start.s_addr) + blobmsg_get_u32(c)); + if ((c = tb[IFACE_ATTR_DHCPV6_PRIVACY])) { + iface->dhcpv6_privacy = blobmsg_get_bool(c); + } + if ((c = tb[IFACE_ATTR_MASTER])) iface->master = blobmsg_get_bool(c); diff --git a/src/dhcpv6-ia.c b/src/dhcpv6-ia.c index fb50448..e9438f6 100644 --- a/src/dhcpv6-ia.c +++ b/src/dhcpv6-ia.c @@ -572,16 +572,37 @@ static bool assign_pd(struct interface *iface, struct dhcpv6_assignment *assign) static bool assign_na(struct interface *iface, struct dhcpv6_assignment *assign) { - /* Seed RNG with checksum of DUID */ uint32_t seed = 0; - for (size_t i = 0; i < assign->clid_len; ++i) + + for (size_t i = 0; i < assign->clid_len; ++i) { + /* Seed RNG with simple sum of DUID */ seed += assign->clid_data[i]; + } + + + if (iface->dhcpv6_privacy) { + /* Little less predictable */ + seed += ((uint32_t)time(NULL)); + } + srand(seed); + /* Try to assign up to 100x */ for (size_t i = 0; i < 100; ++i) { uint32_t try; - do try = ((uint32_t)rand()) % 0x0fff; while (try < 0x100); + + if (iface->dhcpv6_privacy) { + /* DHCPv6+Privacy similar to SLAAC+Privacy */ + do try = (((uint32_t)rand()) * ((uint32_t)rand())) % 0xffffffff; + while (try < 0x10000000); + } + + else { + /* reasonably constant address */ + do try = ((uint32_t)rand()) % 0xffff; + while (try < 0x1000); + } struct dhcpv6_assignment *c; list_for_each_entry(c, &iface->ia_assignments, head) { diff --git a/src/odhcpd.h b/src/odhcpd.h index 538a7e5..d28184d 100644 --- a/src/odhcpd.h +++ b/src/odhcpd.h @@ -152,6 +152,7 @@ struct interface { bool ra_advrouter; bool ra_useleasetime; bool no_dynamic_dhcp; + bool dhcpv6_privacy; // RA int learn_routes;
IP6 SLAAC plus privacy is common. DHCPv6 should be able to provide the same funciton. This way central IT can maintain integrity and traceability. However, individual machines will not be easily placed into a pattern over time by external snooping. 'option dhcpv6_privacy (bool)' is added per interface to switch from reasonablely consistent 16 bit HOSTID to a random rolling 32 bit HOSTID. See FS#403. Signed-off-by: Eric Luehrsen <ericluehrsen@hotmail.com> --- README | 2 ++ src/config.c | 7 +++++++ src/dhcpv6-ia.c | 27 ++++++++++++++++++++++++--- src/odhcpd.h | 1 + 4 files changed, 34 insertions(+), 3 deletions(-)