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

[Qi Sun <[e-mail]>]

Dear Stephen,

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

Cheers,
Qi 

On May 26, 2015, at 8:26 PM, Stephen Farrell <[e-mail]> wrote:

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

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

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

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

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

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

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

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

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

> 
> - section 6, step 6: Could I "release" ports that had not been
> 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.

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

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.

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

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

Thanks a lot!