Minutes for DHC at IETF-91
minutes-91-dhc-1

Meeting Minutes Dynamic Host Configuration (dhc) WG
Title Minutes for DHC at IETF-91
State Active
Other versions plain text
Last updated 2014-11-23

Meeting Minutes
minutes-91-dhc

Agenda:

1. Co-Chairs - Administrativia (Agenda Bashing, WG Status, ...) - 10 minutes
RFC7341(DHCPv4-over-HDCPv6 Transport) published recently.
draft-donley-dhc-cer-id-option should move to Homenet
Ole: 6man tomorrow will present 3 related drafts
WG recharter completed. Call for reviews for milstone drafts.

2. Tomek Mrugalski, DHCPv6bis Update (draft-dhcwg-dhc-rfc3315bis) - 15 minutes
In progress, but still many open issues, particularly, incorporating
stateful-issues DHCPv6bis meeting on Monday, shorter milestones, first monthly
meeting, Dec 10th Call for review for this document. Need one single editor to
make the texts consistent (Bernie may take the role).

Discussion on Client rate limiting (#119)
Initial proposal: 60 messages in 60 seconds, default values, may to tweak it
Ian Farrer: concern about large amount of clients (thousands), What¡¯s the
follow-up Christian Huitema: On the server side, it is an implementation issue.
Daniel: not sure initiate transmissions Bernie: some RFC did similar rate
limiting, might need to look at RFC regarding to ICMP traffic. Tomek: It is the
default value. For cable model, maybe it needs lower. Q1: Do we need
configuration options like SOL_MAX_RT? Ted: I think we don't. Limit is enforced
per link for multiple interface devices.

Discussion on Deprecate IA_TA (#124)
Deprecate means: existing implementations/deployments may use it, new
implementations should skip Ole: lots of work been doing on privacy. Tomek: two
things clarified: deprecate the IA; clients accept the always changing
addresses Ted: don't think it simplified the client lifecycle; should Christian
Huitema: a lot of implementations relay on the association David Lamparter:
less improvement in privacy Sheng Jiang: don't like this proposal on Monday
dhcpv6bis team meeting. Just deprecating it might cause other new issues.
Although there are issues with IA_TA, WG should work on them. Ted Lemon: put
some text in the section like "for server won't give you TAs, this what you can
do" The rough consensus (1 or 2 comments in favor, many against deprecating) in
the room was that IA_TA should not be deprecated. Bernie: next meeting,
dhcpv6bis team meeting will be arranged in the second half of DHC WG meeting to
allow more people participate Sheng Jiang: should adopt this draft before the
next meeting if we want to process it Ted Lemon: encourage to adopt the draft

3. Suresh Krishnan, DHCP privacy considerations - 20 minutes
    Drafts: draft-jiang-dhc-dhcp-privacy and draft-krishnan-dhc-dhcpv6-privacy
Proposal of privacy mitigation is not included. They need to be separated
document. Next step will also include server side privacy. Sheng Jiang: IA_TA
is the major different between DHCPv4 and DHCPv6 Bernie: client-relay actions
or relay-server actions is also relevant, but may need less protection
Discussion on attack use cases Christian Huitema: one possible attack. Proposal
of privacy mitigation is not included Andrew Yourtchenko: DUID will be normally
encrypted, MAC address is open Lorenzo: which thread is stateful and which is
stateless. For stateless, most of these threats go away. Lishan Li: IETF should
consider more on privacy, what protocol should consider privacy? Suresh: IAB
has a privacy document, it's a common consideration. Almost every protocol is
relevant to privacy. Daniel: basically privacy is everywhere Lorenzo: unless
some anti-privacy work. Some protocol may be anti-privacy on purpose. Some
information provided by DHC servers is anti-privacy. Christian: it also depends
on software and IOS version. Legacy software is always problem. Ted lemon:
thread model, what need to be encrypted Suresh: will add use cases. Lorenzo
Colitti: although DHC is bootstrap protocol, should not add too many
configurations. Two goals conflict to each other. Suresh: in RFC new DHCP
option guidance has text for anti-privacy Ted: int directory should do the
work. Lorenzo Colitti: infrastructure problem, if the information is needed by
user, then privacy could be problematic. Tomek: will adopt the privacy problem
analysis drafts soon. And will need mitigation draft. Marcin Siodelski: the
draft to be informational or standard track? Suresh: informational Tomek:
mitigation draft might be info or BCP, but will decide later

4. Marcin Siodelski and Bernie Volz - draft-ietf-dhc-dhcpv6-stateful-issues -
15 minutes Ian: 3633 doesn't specify the behavior, if relays repeat and repeat
Renew/Rebind Bernie: have a ticket in 3315bis, but not really deal with it
Presenting updates in -07 and -08. Tim Winters: Is there a text what clients do
with T1=T2=0? If clients choose a value, it should choose the same for all IAs.
Ted: what is the actual semantic meaning of T1=T2=0, in what situation it make
sense? Ted: the original question is the client should renew before the
shortest expires Tim Winters: I have 2 major implementations that send them as
0s. You'll have major interoperation problems if clients start rejecting them.
Ted: we wrote this kind of implementation Bernie: 3315bis should clarify this
issue Ted: We may disallow the servers to send it and let clients to process
it. Andrew: relaying a comment from jabber from Qi Sun: does the draft covers
also any other future IAs? Marcin: No, we explicitly limited the draft to IA_NA
and IA_PD only. Bernie: It doesn't make sense to cover any future IAs as we
don't know what their use cases and lifecycle would be. Marcin: Thanks to the
reviewers that volunteered during IETF90. Unfortunately only 2 out of 8
reviewed. Still pending reviews from Leaf Yeh, Francis Dupont, Jason Weil, Ian
Farrer, Qi Sun, Cong Liu. Asking for additional reviewers: Suresh Krishnan, Ted
Lemon, Tim Winters and Tomek Mrugalski signed up.

5. Lishan Li - draft-cui-dhc-dhcp4o6-active-leasequery - 15 min
Bernie: DHCP in IPv6 tunnel draft is in softwires Working Group.
Marcin: bulk leasequery requires leasequery to be implemented
Ian: whether source address option carried in v4 option. We will send the
option draft to dhc WG for review. Note: The related option discussed is
defined in draft-fsc-softwire-dhcp4o6-saddr-opt. Bernie: we need to review it
along with the 4o6 leasequery draft and will see what the next steps are.

6. Fred L. Templin - draft-templin-aerolink - 15 minutes
Bernie: this presentation is purely informational for DHC, DHC won't do the
work. Fred: we have an unsolved issue:        how the server know client is
authorized to use its claimed Client ID (DUID) Sheng Jiang: confused by the
requirement. This may have to request that dhcp server statefully assign and
manage the client DUID. The DUID is generated by client, why it should be
authorized by the server. Fred: requirement is server need to authorize the
client Christian: if you need this, just restore clients' certificates in the
server. Sheng: this is also supported in secure DHCPv6 Fred: that should solve
out requirements ¡¡¡¡

¡¡¡¡

¡¡¡¡

¡¡¡¡