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

[Stephen Farrell <[e-mail]>]

Hiya,

Thanks for the quick response, some follow ups below.

On 27/05/15 15:03, Qi Sun wrote:
> 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?

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

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

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

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

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

Cheers,
S.


> 
> Thanks a lot!
> 
>