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

[Qi Sun <[e-mail]>]

Dear Stephen, 

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

Cheers,
Qi

On May 27, 2015, at 10:32 PM, Stephen Farrell <[e-mail]> wrote:

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

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

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

[Qi] Got your point :)

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

[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
> 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] Hope the explanations could help!

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

[Qi] Thanks.

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

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

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

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

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

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

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

[Qi] OK.

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

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

> 
> Cheers,
> S.
> 
> 
>> 
>> Thanks a lot!