Subject: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-dynamic-shared-v4allocation-07: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 26 May 2015 05:26:30 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-dhc-dynamic-shared-v4allocation-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dynamic-shared-v4allocation/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

section 6: Why is client identifier option a MUST?  Surely the
PSID has to end up as a unique identifier for the client for the
duration of the lease or else stuff will be broken. (And I don't
see any real use of the client identifier in section 8.) So
requiring the client identifier seems like something counter to
data minimisation. Requiring that also seems to conflict with
possible future privacy friendly dhcp profiles, which might want
to use this as e.g. with some cleverness in source port
randomisation, the public Internet might get less trackable
evidence than would otherwise be the case. I'd argue that you
might be better off here to make the client identifier a SHOULD
NOT and to point out that including it may break a privacy
friendly profile such as defined in [1] should that end up being
standardised, which is presumably likely now that [1] is a dhc
wg draft (though note that I'm not sure the treatment of client
identifier in [1]-02 is what'll end up there in the end.)

   [1] https://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-00

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- section 2: s/mediums/media/? I also wondered if cable is
considered shared here or not? (I assume Ethernet and WiFi are
considered shared.)

- What if 1 of N of the devices with that IP operates a server,
how do we ensure that clients of that server talk to the right
one? 

- I have some questions about ports. Can I ask for port 546 or
547? Why is that ever allowed?  Would port 443 be very popular I
wonder?  Can I ask for other well known ports in the hopes of
successful typosquatting sending me traffic?  What if mptcp is
used?

- section 6, step 3: I'm not sure I get how there can be many
DHCPOFFER messages from which to choose (in the nominal case).
Are you envisaging that two DHCP relays/servers on the same
subnet would be handing out different PSIDs? 

- section 6, step 6: Could I "release" ports that had not been
assigned to me? Where's it say to watch out for that.

- section 9: PSID-len - the description of that isn't clear to
me sorry. I've not followed the references though so I assume it
would be if I had. 

- section 10: [I-D.bajko-pripaddrassign] is odd - that was
replaced by stuff that was replaced by stuff that was replaced
by stuff that's still in-work in the dhc wg. I think you need to
explain why you refer to the archaic thing and not the WG
document.

---

From: Qi Sun <[email-masked]>
Date: Wed, 27 May 2015 22:03:21 +0800

Dear Stephen,

Many thanks for the careful review! Please see inline for our response to the questions.

Cheers,
Qi 

> https://datatracker.ietf.org/doc/draft-ietf-dhc-dynamic-shared-v4allocation/

[Qi] The use of client identifier does not interfere with privacy profile. In sec3.4 of draft-ietf-dhc-anonymity-profile-00, it says:

   The recommendations in [RFC4361] are very strong, stating for example
   that "DHCPv4 clients MUST NOT use client identifiers based solely on
   layer two addresses that are hard-wired to the layer two device
   (e.g., the Ethernet MAC address)."  These strong recommendations are
   in fact a tradeoff between ease of management and privacy, and the
   tradeoff should depend on the circumstances.

   In contradiction to [RFC4361], When using the anonymity profile, DHCP
   clients MUST use client identifiers based solely on the link layer
   address that will be used in the underlying connection.  This will
   ensure that the DHCP client identifier does not leak any information
   that is not already available to entities monitoring the network
   connection.  It will also ensure that a strategy of randomizing the
   link layer address will not be nullified by DHCP options.

draft-ietf-dhc-dynamic-shared-v4allocation does not specify what information to convey in the client identifier option, so an implementation can be fully compliant with RFC4361 or a privacy profile.

[Qi] Thanks for spotting this. IMHO, cable is also considered as shared medium. How about the following change:
OLD:
  It is not suitable for network access over shared mediums.

NEW: 
   It is not suitable for network access over shared media, including Ethernet, WiFi, cable, etc.

> how do we ensure that clients of that server talk to the right

[Qi] IMHO, how a host makes use of a port restricted IP address is out of the scope for this document. This document does not define an A+P architecture but only the DHCPv4 provisioning part.

> successful typosquatting sending me traffic?  What if mptcp is

[Qi] IMHO, the questions are more about how a device operates in the context of IPv4 address sharing, which should be handled by A+P architecture docs. 

AND:
1) This draft provides the client the ability to indicate preferred ports but it is up to the server to decide:

       The client MAY insert an
       OPTION_V4_PORTPARAMS with preferred values in related fields as a
       suggestion to the DHCP 4o6 Server.

There is also some text about the well-known ports on the server side:

In section 8:
  When defining the pools of IPv4 addresses and PSIDs which are
  available to lease to clients, the server MUST implement a mechanism
  to reserve some port ranges (e.g., 0-1023) from allocation to
  clients.  The reservation policy SHOULD be configurable.

In section 9:
  In order to exclude the system ports ([RFC6335]) or ports reserved by
  ISPs, the former port-sets that contain well-known ports MUST NOT be
  assigned unless the operator has explicitly configured otherwise
  (e.g., by allocating a full IPv4 address).

Could those address your questions?

2) About MPTCP, I think the connections should use source ports from the allocated port range, which is similar to normal case. An MPTCP client can indicate a restricted port number as part of MPTCP options.

> subnet would be handing out different PSIDs? 

[Qi] There might be multiple relays/servers on the subnet.  Different servers run different address+port set pools, which might result in different sizes/values of PSIDs, depending on the servers’ configuration. Other DHCP parameters might also be different. And RFC2131 is quite unrestrictive in describing which mechanism is used for the client to select between the different offers.

> assigned to me? Where's it say to watch out for that.

[Qi] Normally, the client can only release a DHCP lease that was allocated to it. If a malicious client intends to release a PSID that was not assigned to it, the current text says something about the server’s behaviour in Sec8:
OLD:
   Upon receipt of a DHCPRELEASE message with OPTION_V4_PORTPARAMS, the
   server searches for the lease using the address in the 'ciaddr' field
   and the PSID information in the OPTION_V4_PORTPARAMS, and marks the
   lease as unallocated.

This text assumes implicitly that a look up based on the content of the parameters in the release request is performed. No lease will be found if the server didn’t assigned a port set to a client. How about the following change:
NEW:
   Upon receipt of a DHCPRELEASE message with OPTION_V4_PORTPARAMS, the
   server searches for the lease using the address in the 'ciaddr' field
   and the PSID information in the OPTION_V4_PORTPARAMS, and marks the
   lease as unallocated if a record (matching that PSID) is maintained by the server for that client.

> me sorry. I've not followed the references though so I assume it

[Qi] Sorry for not describing it clearly. But the text is taken from draft-ietf-softwire-map-dhcp-12#section-4.5, for the purpose of consistence.

The PSID is part of a port number. According to MAP specification, a port number consists of PSID-Offset (a bits), PSID-value (k bits) and remaining bits (m bits). ‘a’, ‘k’ and the value of PSID are provisioned through DHCP option. The PSID should not be greater than 16 bits in length. But in order to construct this DHCP option, the PSID field here is specified as 16-bit long. Only the first ‘k’ bits are the actual value of PSID. That’s what we intend to describe.

How about the following modification:

OLD:

  o  PSID-len: Bit length value of the number of significant bits in
      the PSID field (also known as 'k').  When set to 0, the PSID field
      is to be ignored.  After the first 'a' bits, there are k bits in
      the port number representing the value of PSID.  Subsequently, the
      address sharing ratio would be 2^k.

NEW:

PSID-len: The length in bits of the significant bits in the PSID
      field (given the value 'k'). When set to 0, the PSID field
      is to be ignored (a full IPv4 address is allocated). When
      PSID-len > 0, the PSID field is interpreted as described in the
      paragraph below.
PSID: Explicit 16-bit (unsigned word) PSID value.  The PSID value
      algorithmically identifies a set of ports assigned to a client.
      From left to right, this is comprised of the ‘a’ bits (length
      defined in the Offset field), followed by the ‘k’ bits (length
      defined in the PSID-len field) which contains the PSID that
      is being allocated to the client.  The remaining (16-k) bits
      on the right are padding zeros.

> explain why you refer to the archaic thing and not the WG

[Qi] Thanks for the observation! The reason why we are keeping that reference is that, in Sec 5 of [I-D.bajko-pripaddrassign], there was a “Random Port Delegation Function” defined. When we tried to merge/‘replace’ drafts, that part was considered complicated and was not included in the replacing document(s). So we only keep a pointer there. 

Could we resolve this by dropping that reference, since all needed information is in the current draft?

Thanks a lot!

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 May 2015 15:32:17 +0100

Hiya,

Thanks for the quick response, some follow ups below.

On 27/05/15 15:03, Qi Sun wrote:
> Cheers, Qi
>> When responding, please keep the subject line intact and reply to
>> all email addresses included in the To and CC lines. (Feel free to
>> cut this introductory paragraph, however.)
>> 
>> 
>> Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
>> information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> section 6: Why is client identifier option a MUST?

I don't believe I saw an answer to the question above. What
is the answer? (I think that is the key thing in figuring out
how to handle the discuss btw.)

>> Surely the
>> possible future privacy friendly dhcp profiles, which might want to
>> use this as e.g. with some cleverness in source port randomisation,
>> the public Internet might get less trackable evidence than would
>> otherwise be the case. I'd argue that you might be better off here
>> to make the client identifier a SHOULD NOT and to point out that
>> including it may break a privacy friendly profile such as defined
>> in [1] should that end up being standardised, which is presumably
>> likely now that [1] is a dhc wg draft (though note that I'm not
>> sure the treatment of client identifier in [1]-02 is what'll end up
>> there in the end.)
>> 
>> [1]
>> https://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-00
>> 
> 
> [Qi] The use of client identifier does not interfere with privacy
> profile. In sec3.4 of draft-ietf-dhc-anonymity-profile-00, it says:
> 
> The recommendations in [RFC4361] are very strong, stating for
> example that "DHCPv4 clients MUST NOT use client identifiers based
> solely on layer two addresses that are hard-wired to the layer two
> device (e.g., the Ethernet MAC address)."  These strong
> recommendations are in fact a tradeoff between ease of management and
> privacy, and the tradeoff should depend on the circumstances.
> 
> In contradiction to [RFC4361], When using the anonymity profile,
> DHCP clients MUST use client identifiers based solely on the link
> layer address that will be used in the underlying connection.  This
> will ensure that the DHCP client identifier does not leak any
> information that is not already available to entities monitoring the
> network connection.  It will also ensure that a strategy of
> randomizing the link layer address will not be nullified by DHCP
> options.

I'll just note that the anonymity thing is a -00 so we've
not that much clue what it'll end up saying about the use
of client identifier (or at least I don't:-). For example,
if the MAC address of an identifier is used and if there
is a DHCP relay, then that would I think expose more than
desirable or needed. And if the MAC address was used and
the 808.11 layer is randomising MACs then that might break
something another way. So I'm not sure the above text won't
need substantial modification.

> 
> draft-ietf-dhc-dynamic-shared-v4allocation does not specify what
> information to convey in the client identifier option, so an
> implementation can be fully compliant with RFC4361 or a privacy
> profile.

Again though, if any value is ok, then why do you need it
to be a MUST? I think you could just omit all mention of
client identifier and be fine. (Or you could if you wanted
be extra privacy friendly and say it SHOULD NOT be sent,
assuming that doesn't break anything.)

> [Qi] Thanks for spotting this. IMHO, cable is also considered as
> shared medium. How about the following change: OLD: It is not
> suitable for network access over shared mediums.
> 
> NEW: It is not suitable for network access over shared media,
> including Ethernet, WiFi, cable, etc.

WFM

> 
>> 
>> - What if 1 of N of the devices with that IP operates a server, how
>> do we ensure that clients of that server talk to the right one?
> 
> [Qi] IMHO, how a host makes use of a port restricted IP address is
> out of the scope for this document. This document does not define an
> A+P architecture but only the DHCPv4 provisioning part.

Hmm. Ok. But I didn't ask how this document says that ought work,
I was wondering how it could work.

>> 
>> - I have some questions about ports. Can I ask for port 546 or 547?
>> Why is that ever allowed?  

It seems a bit crazy to me to perhaps allow a client to
use this mechanism to break this mechanism. Isn't that
what giving out 546 would mean? (For N-1 of the N clients
who got that same address.)

>> Would port 443 be very popular I wonder?
>> Can I ask for other well known ports in the hopes of successful
>> typosquatting sending me traffic?  What if mptcp is used?
> 
> [Qi] IMHO, the questions are more about how a device operates in the
> context of IPv4 address sharing, which should be handled by A+P
> architecture docs.

I do think the typosquatting aspect could be worth a mention
in the security considerations. Your call though.

> 
> AND: 1) This draft provides the client the ability to indicate
> preferred ports but it is up to the server to decide:
> 
> The client MAY insert an OPTION_V4_PORTPARAMS with preferred values
> in related fields as a suggestion to the DHCP 4o6 Server.
> 
> In section 8: When defining the pools of IPv4 addresses and PSIDs
> which are available to lease to clients, the server MUST implement a
> mechanism to reserve some port ranges (e.g., 0-1023) from allocation
> to clients.  The reservation policy SHOULD be configurable.
> 
> In section 9: In order to exclude the system ports ([RFC6335]) or
> ports reserved by ISPs, the former port-sets that contain well-known
> ports MUST NOT be assigned unless the operator has explicitly
> configured otherwise (e.g., by allocating a full IPv4 address).
> 
> 2) About MPTCP, I think the connections should use source ports from
> the allocated port range, which is similar to normal case. An MPTCP
> client can indicate a restricted port number as part of MPTCP
> options.
> 
>> 
>> DHCPOFFER messages from which to choose (in the nominal case). Are
>> you envisaging that two DHCP relays/servers on the same subnet
>> would be handing out different PSIDs?
> 
> [Qi] There might be multiple relays/servers on the subnet.  Different
> servers run different address+port set pools, which might result in
> different sizes/values of PSIDs, depending on the servers’
> configuration. Other DHCP parameters might also be different. And
> RFC2131 is quite unrestrictive in describing which mechanism is used
> for the client to select between the different offers.
> 
>> 
> [Qi] Normally, the client can only release a DHCP lease that was
> allocated to it. If a malicious client intends to release a PSID that
> was not assigned to it, the current text says something about the
> server’s behaviour in Sec8: OLD: Upon receipt of a DHCPRELEASE
> message with OPTION_V4_PORTPARAMS, the server searches for the lease
> using the address in the 'ciaddr' field and the PSID information in
> the OPTION_V4_PORTPARAMS, and marks the lease as unallocated.
> 
> This text assumes implicitly that a look up based on the content of
> the parameters in the release request is performed. No lease will be
> found if the server didn’t assigned a port set to a client. How about
> the following change: NEW: Upon receipt of a DHCPRELEASE message with
> OPTION_V4_PORTPARAMS, the server searches for the lease using the
> address in the 'ciaddr' field and the PSID information in the
> OPTION_V4_PORTPARAMS, and marks the lease as unallocated if a record
> (matching that PSID) is maintained by the server for that client.
> 
>> 
>> - section 9: PSID-len - the description of that isn't clear to me
>> sorry. I've not followed the references though so I assume it would
>> be if I had.
> 
> [Qi] Sorry for not describing it clearly. But the text is taken from
> draft-ietf-softwire-map-dhcp-12#section-4.5, for the purpose of
> consistence.
> 
> The PSID is part of a port number. According to MAP specification, a
> port number consists of PSID-Offset (a bits), PSID-value (k bits) and
> remaining bits (m bits). ‘a’, ‘k’ and the value of PSID are
> provisioned through DHCP option. The PSID should not be greater than
> 16 bits in length. But in order to construct this DHCP option, the
> PSID field here is specified as 16-bit long. Only the first ‘k’ bits
> are the actual value of PSID. That’s what we intend to describe.
> 
> the PSID field (also known as 'k').  When set to 0, the PSID field is
> to be ignored.  After the first 'a' bits, there are k bits in the
> port number representing the value of PSID.  Subsequently, the 
> field (given the value 'k'). When set to 0, the PSID field is to be
> ignored (a full IPv4 address is allocated). When PSID-len > 0, the
> PSID field is interpreted as described in the paragraph below. PSID:
> Explicit 16-bit (unsigned word) PSID value.  The PSID value 
> algorithmically identifies a set of ports assigned to a client. From
> left to right, this is comprised of the ‘a’ bits (length defined in
> the Offset field), followed by the ‘k’ bits (length defined in the
> PSID-len field) which contains the PSID that is being allocated to
> the client.  The remaining (16-k) bits on the right are padding
> zeros.

I think maybe the OLD text is better really since it's better
to not replicate such text. That does make it harder to
understand (which was my comment) but on balance it's better to
be correct for stuff like that.

> 
>> 
>> - section 10: [I-D.bajko-pripaddrassign] is odd - that was replaced
>> by stuff that was replaced by stuff that was replaced by stuff
>> that's still in-work in the dhc wg. I think you need to explain why
>> you refer to the archaic thing and not the WG document.
> 
> [Qi] Thanks for the observation! The reason why we are keeping that
> reference is that, in Sec 5 of [I-D.bajko-pripaddrassign], there was
> a “Random Port Delegation Function” defined. When we tried to
> merge/‘replace’ drafts, that part was considered complicated and was
> not included in the replacing document(s). So we only keep a pointer
> there.
> 

Yes. If the current text is enough without that reference then
getting rid of that weird reference is better. If you need the
reference because of something in that draft that was dropped by
the WG then I think you have a problem since that would mean that
part of this draft is in conflict with the WG consensus on
another.

Cheers,
S.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 27 May 2015 15:16:48 -0400

> how to handle the discuss btw.)

The base protocol specification uses either the client identifier option or the client MAC address as an identifier.   This document is requiring the use of the client identifier option, and excludes the use of the MAC address, which potentially increases user privacy in the event that the DHCP privacy profile is used.   If the specification allowed the client to use its MAC address alone as an identifier, this would not be possible.

However, I think the actual reason that the client identifier is being required here is that the specific interface that is being configured on the client is not a hardware interface--it's a virtual point-to-point link, which has no hardware address, and thus the client identifier is the only possible identifier to use.

The client identifier or MAC address is used as a database key by the DHCP server to track resources allocated to the client: in this case the A+P port set.   Without such a key, there would be no way to renew the client's lease on that particular A+P port set, and so TCP connections would be broken each time the client's lease expired.

---

From: Qi Sun <[email-masked]>
Date: Thu, 28 May 2015 13:22:39 +0800

Dear Stephen, 

Sorry for late response because of time difference. Please see inline. 
Thank you!

Cheers,
Qi

> how to handle the discuss btw.)

[Qi] I echo Ted here. The client identifier is required for identify the client as well as the lease allocated to that client. It’s necessary for tracking the status of a specific lease, and is used when RENEW / RELEASE a ’shared IPv4’ lease. As the underlay should (normally) be a point-to-point virtual link, using client identifier can guarantee the mechanism to work properly.  

> need substantial modification.

[Qi] Got your point :)

> to be a MUST?

[Qi] No matter what the value is, it’s still a unique identifier that identifies the client and the lease. The value is determined by other algorithm(s), just as in DHCPv4/DHCPv6. We use a MUST on the client identifier intends for DHCP operations like RENEW, RELEASE, etc. to work as current practice. 

> I think you could just omit all mention of

[Qi] Hope the explanations could help!

>> including Ethernet, WiFi, cable, etc.

[Qi] Thanks.

> I was wondering how it could work.

[Qi] When developing A+P transition mechanisms like MAP, lw4o6, the agreement is that if a host wants to operate as a server, it needs to pay more money for a full IPv4 address for ‘better’ service. The case you described is kind of complicated and might be better to avoid, at lease from the provisioning (server) side. 

> who got that same address.)

[Qi] Thanks for the explanation. As described in the current text, the client could give a hint to the server for what port range it desires, but the server has the right to ignore that hint but allocates another port range out side the well-known ports. The mechanism requires that a server MUST be able to reserve port ranges and MUST NOT assign the port set(s) including well-known ports. That’s our consideration.

> in the security considerations. Your call though.

[Qi] Could you please elaborate on the problematic case? My understanding is that a sever compliant to this document is not allowed to allocate well-known ports if the client is requesting OPTION_V4_PORTPARAMS for sharing IPv4. So I think traffic from successful typosquatting would be dropped. But maybe I missed something… Please point it out if so. Thanks!

> be correct for stuff like that.

[Qi] OK.

> part of this draft is in conflict with the WG consensus on

[Qi] Thanks for the guidance. We’ll remove that reference. Thanks.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 May 2015 12:22:53 +0100

Hi Ted,

On 27/05/15 20:16, Ted Lemon wrote:
>> I don't believe I saw an answer to the question above. What is the
>> answer? (I think that is the key thing in figuring out how to
>> handle the discuss btw.)
> 
> The base protocol specification uses either the client identifier
> option or the client MAC address as an identifier.   This document is
> requiring the use of the client identifier option, and excludes the
> use of the MAC address, which potentially increases user privacy in
> the event that the DHCP privacy profile is used.   If the
> specification allowed the client to use its MAC address alone as an
> identifier, this would not be possible.
> 
> However, I think the actual reason that the client identifier is
> being required here is that the specific interface that is being
> configured on the client is not a hardware interface--it's a virtual
> point-to-point link, which has no hardware address, and thus the
> client identifier is the only possible identifier to use.

But isn't the PSID here exactly the idenfier needed (plus the address
where one's been allocated)?

S.

> 
> The client identifier or MAC address is used as a database key by the
> DHCP server to track resources allocated to the client: in this case
> the A+P port set.   Without such a key, there would be no way to
> renew the client's lease on that particular A+P port set, and so TCP
> connections would be broken each time the client's lease expired.
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 28 May 2015 11:33:17 +0000

There is no PSID at the start of client allocation request (DHCPDISCOVER) and client id is from the client to the server in DHCP. DHCP client identity is based on mac-address (already explained why not appropriate) or client id option. Why would we want to change this?

- Bernie

> On May 28, 2015, at 7:22 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Ted,
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 May 2015 12:47:14 +0100

On 28/05/15 12:33, Bernie Volz (volz) wrote:
> There is no PSID at the start of client allocation request
> (DHCPDISCOVER) 

Maybe I'm mis reading the draft but I thought it was saying
client identifier was a MUST in all cases, and not only
for DHCPDISCOVER.

If it said client identifier was needed in case <foo> but
otherwise could be omitted (assuming that works) then I
think that'd be better.

> and client id is from the client to the server in
> DHCP. DHCP client identity is based on mac-address (already explained
> why not appropriate) or client id option. Why would we want to change
> this?

I'm not suggesting a change like that, but only to omit
the identifying information when that's possible.

S

>>> On 27/05/15 20:16, Ted Lemon wrote: On May 27, 2015, at 10:32 AM,
>>> Stephen Farrell <[email-masked]> wrote:
>>>> I don't believe I saw an answer to the question above. What is
>>>> the answer? (I think that is the key thing in figuring out how
>>>> to handle the discuss btw.)
>>> 
>>> The base protocol specification uses either the client
>>> identifier option or the client MAC address as an identifier.
>>> This document is requiring the use of the client identifier
>>> option, and excludes the use of the MAC address, which
>>> potentially increases user privacy in the event that the DHCP
>>> privacy profile is used.   If the specification allowed the
>>> client to use its MAC address alone as an identifier, this would
>>> not be possible.
>>> 
>>> configured on the client is not a hardware interface--it's a
>>> virtual point-to-point link, which has no hardware address, and
>>> thus the client identifier is the only possible identifier to
>>> use.
>> 
>> But isn't the PSID here exactly the idenfier needed (plus the
>> address where one's been allocated)?
>> 
>> S.
>> 
>>> 
>>> The client identifier or MAC address is used as a database key by
>>> the DHCP server to track resources allocated to the client: in
>>> this case the A+P port set.   Without such a key, there would be
>>> no way to renew the client's lease on that particular A+P port
>>> set, and so TCP connections would be broken each time the
>>> client's lease expired.
>>>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 28 May 2015 11:49:23 +0000

The client always most identify itself consistently in all packets sent by the client to the server - and for DHCP that is again either by mac-address or client-identifier option.

I do not think it appropriate to change how DHCP works in this document.

- Bernie

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, May 28, 2015 7:47 AM
To: Bernie Volz (volz)
Cc: Ted Lemon; Qi Sun; <[email-masked]>; <[email-masked]>; <[email-masked]>; The IESG; <[email-masked]>; <[email-masked]>
Subject: Re: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-dynamic-shared-v4allocation-07: (with DISCUSS and COMMENT)

> There is no PSID at the start of client allocation request

Maybe I'm mis reading the draft but I thought it was saying client identifier was a MUST in all cases, and not only for DHCPDISCOVER.

If it said client identifier was needed in case <foo> but otherwise could be omitted (assuming that works) then I think that'd be better.

> and client id is from the client to the server in DHCP. DHCP client 
> identity is based on mac-address (already explained why not 
> appropriate) or client id option. Why would we want to change this?

I'm not suggesting a change like that, but only to omit the identifying information when that's possible.

S

>>> option or the client MAC address as an identifier.
>>> This document is requiring the use of the client identifier option, 
>>> and excludes the use of the MAC address, which potentially increases 
>>> user privacy in the event that the DHCP
>>> client to use its MAC address alone as an identifier, this would not 
>>> be possible.
>>> 
>>> no way to renew the client's lease on that particular A+P port set, 
>>> and so TCP connections would be broken each time the client's lease 
>>> expired.
>>>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 May 2015 12:52:25 +0100

> I do not think it appropriate to change how DHCP works in this document.

So that confuses me. If the above is an inherent necessity for dhcp
then why does the current document need a 2119 MUST?

S.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 28 May 2015 11:55:28 +0000

It needs a MUST because the DHCP protocol (RFC 2131/2132) specifies that the client-identifier option is OPTIONAL. If not present, the mac-address is used. And as has already been discussed, the mac-address is not a good choice here because of the tunnel interface.

Thus, this document REQUIRES that the client use the client-identifier option when using shared-v4-allocation requests - the option is not optional.

- Bernie
 
-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, May 28, 2015 7:52 AM
To: Bernie Volz (volz)
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; Qi Sun; The IESG; <[email-masked]>; Ted Lemon
Subject: Re: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-dynamic-shared-v4allocation-07: (with DISCUSS and COMMENT)

> I do not think it appropriate to change how DHCP works in this document.

So that confuses me. If the above is an inherent necessity for dhcp then why does the current document need a 2119 MUST?

S.

> Cc: Ted Lemon; Qi Sun; 
> <[email-masked]>; 
> <[email-masked]>; 
> <[email-masked]>; The IESG; 
> <[email-masked]>; 
> <[email-masked]>
> Subject: Re: [dhcwg] Stephen Farrell's Discuss on 
> draft-ietf-dhc-dynamic-shared-v4allocation-07: (with DISCUSS and 
> COMMENT)
> 
> 
> 
>>>> and excludes the use of the MAC address, which potentially 
>>>> increases user privacy in the event that the DHCP
>>>> thus the client identifier is the only possible identifier to use.
>>>

---

From: [email-masked]
Date: Thu, 28 May 2015 14:11:05 +0200 (CEST)

> Thus, this document REQUIRES that the client use the client-identifier option when using shared-v4-allocation requests - the option is not optional.

I understand the reasoning behind the requirement. However - as far as
I know, Windows is (by far) the most common user of client-identifier
- and sets the client identifier to the same value as the MAC address.

Do we have reason to believe that the Windows behavior would be changed
given a MUST in this document?

Steinar Haug, AS 2116

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 28 May 2015 12:19:32 +0000

If Windows were to implement this support, I am sure they would make use of an appropriate identifier.

Note also that there is work going on in the DHC WG to address privacy issues - see draft-ietf-dhc-anonymity-profile-00. And one of the authors (the primary author) is from Microsoft so I am sure this is on their radar.

- Bernie 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, May 28, 2015 8:11 AM
To: Bernie Volz (volz)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-dynamic-shared-v4allocation-07: (with DISCUSS and COMMENT)

> Thus, this document REQUIRES that the client use the client-identifier option when using shared-v4-allocation requests - the option is not optional.

I understand the reasoning behind the requirement. However - as far as I know, Windows is (by far) the most common user of client-identifier
- and sets the client identifier to the same value as the MAC address.

Do we have reason to believe that the Windows behavior would be changed given a MUST in this document?

Steinar Haug, AS 2116

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 May 2015 13:22:33 +0100

On 28/05/15 13:19, Bernie Volz (volz) wrote:
> Note also that there is work going on in the DHC WG to address
> privacy issues - see draft-ietf-dhc-anonymity-profile-00. And one of
> the authors (the primary author) is from Microsoft so I am sure this
> is on their radar.

So just to be clear: the reason I'm asking about this is mainly
that I want to be sure that this draft doesn't make deploying
the privacy one harder/impossible.

S.

PS: Am in a bit of a rush to get something else done right now
so probably won't be able to continue this discussion until later
or tomorrow.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 28 May 2015 13:39:53 +0000

I understand that is your goal. But we haven't really resolved this issue as to how to generate a replacement client identity.

Note that DHCP "needs" the identifier for a client to be unique so that the server can correctly identify whether this is a new or different client - otherwise, the server may assign the same address (and psid) to two clients if they happen to be connected at the same time which creates all sorts of other issues (duplicate address assignment).

And, shared-v4allocation is requiring use of the client-id and the format as described in RFC 4361 (which is based on the DHCPv6 DUID).

In the case of 4o6 (such as draft-ietf-softwire-lw4over6), I would suggest that this client identifier could likely be the same as was used (or would be used) for DHCPv6 for the underlying interface. But perhaps someone will respond as to why that may not be a good idea.

But this would at least solve part of the problem - we still have to fix the DHCPv6 DUID, but this doesn't create a new identifier (since it was already used by the client).

- Bernie

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, May 28, 2015 8:23 AM
To: Bernie Volz (volz); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-dynamic-shared-v4allocation-07: (with DISCUSS and COMMENT)

On 28/05/15 13:19, Bernie Volz (volz) wrote:
> Note also that there is work going on in the DHC WG to address privacy 
> issues - see draft-ietf-dhc-anonymity-profile-00. And one of the 
> authors (the primary author) is from Microsoft so I am sure this is on 
> their radar.

So just to be clear: the reason I'm asking about this is mainly that I want to be sure that this draft doesn't make deploying the privacy one harder/impossible.

S.

PS: Am in a bit of a rush to get something else done right now so probably won't be able to continue this discussion until later or tomorrow.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 28 May 2015 10:06:42 -0400

> given a MUST in this document?

We can speculate, based on the fact that one of the leading proponents of the DHCP privacy specification is a Microsoft employee, that this could happen for future versions of Microsoft's products.   I think it's unlikely that the fix will be retroactive.   But what do I know?   Speculation is somewhat silly, and also immaterial, since in this case the MAC address can't be used as an identifier, and Windows isn't really the target for this work—we are likely to see most implementations in home router firmware.

---

From: Qi Sun <[email-masked]>
Date: Thu, 28 May 2015 22:07:12 +0800

Dear Stephen,

A side note (maybe you’ve already noted it) is that, the Client Identifier option is also part of the DHCPv4 anonymity profile (Section 3.4). I assume draft-ietf-dhc-anonymity-profile-00 is not intending to obsolete client identifier since it’s needed for DHCP to work. 

Thanks,
Qi

---

From: Ted Lemon <[email-masked]>
Date: Thu, 28 May 2015 10:16:34 -0400

> the privacy one harder/impossible.

There are two points to keep in mind about this.   First, I think it actually makes it easier, because now the client identifier is required and the MAC address is not needed, so at a minimum it's at least easier to avoid including a consistent identifier in requests that might happen on different networks.   But secondly, the target for this specification is really home gateways, and the issues of roaming from network to network are at least at present pretty minimal.   Whether home gateway vendors implement the privacy doc or not, I think the risk to end users' privacy is limited since the upstream ISP presumably already knows who the customer is.

As for the port set ID as an identifier, it's just the opposite: it's the thing being allocated. Think of it as an IPv4 address, only with more bits.   It identifies the address and port range that has been allocated, not the client to which it has been allocated. It is sent by the client as an indication of which port set was previously allocated to the client, not as an identifier.  The client can be expected to have different port sets at different times. So it simply doesn't make sense to use it the way you are suggesting.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 28 May 2015 17:27:57 +0000

On May 28, 2015 5:23 AM, Stephen Farrell wrote: 
> So just to be clear: the reason I'm asking about this is mainly that I want to be
> sure that this draft doesn't make deploying the privacy one harder/impossible.

How about adding something like that to the security considerations:

The purpose of the "client identifier option" is to ensure that the same client retains the same parameters over time. This interferes with the client's privacy, as it allows the server to track the client. Clients can manage their privacy exposure by controlling the value of the client identifier, trading off stability of parameter allocation for privacy. We expect that guidance on this tradeoff will be discussed in a future version of [draft-ietf-dhc-anonymity-profile].

-- Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 May 2015 18:57:33 +0100

> The purpose of the "client identifier option" is to ensure that the same client retains the same parameters over time. This interferes with the client's privacy, as it allows the server to track th…

That'd work for me. Authors?

S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 May 2015 09:23:36 +0100

So that change was done and I've cleared the discuss. Thanks
all.

I'm happy to chat about any remaining comments - I didn't
check if related changes there have been made.

Cheers,
S.