Subject: [dhcwg] light review of draft-ietf-dhc-sedhcpv6 and helpful suggestion

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 17 Apr 2017 16:43:00 -0400

Dear authors,

I just skimmed the draft  triggered by another review and noticed the
deployment concerns in the WGLC summary sent to the list.  think I can
help here with the remaining issues on making it easier to deploy.

First, I'm really glad to see this work.  Thanks for all of your
efforts on it!  Second, I know this is late in the process, but I
think more text on opportunistic security for IPsec is worth
documenting to overcome implementation hurdles and address the coffee
shop use cases.  I didn't see a reference to:

https://tools.ietf.org/html/rfc7619

and am thinking the authors/WG might not be aware of this work.
Additionally, it should be noted that there are several Linux
implementations for IPsec with NULL authentication (OS).  Paul
Woulters is a author on the mentioned RFC and did implement this with
IPsec for RedHat.

Michael Richardson is an author on the draft:
https://tools.ietf.org/html/draft-richardson-ipsec-opportunistic-17

documenting the OS IPsec implementation for the Linux FreeS/WAN project.

I think it would be beneficial to see text that has OS as mandatory to
implement (MTI) and upgradeable to authenticated IPsec when practical.
Ideally, they would both be MTI, not mandatory to use (MTU) at least
for the authenticated since that is too hard.  But MTI on
opportunistic would be a great next step that could be deployed.  If
we were able to get DCHPv6 supporting this option in code with OS,
then people could turn it on.  As you point out in the draft,
enterprise and other managed scenarios could use an option with
authentication if implemented.  I think the MTI versus MTU could have
been more clear in this draft and the relay one that just went through
the IESG review.

The current OS text leaves me, the reader, thinking it won't be
implemented as it's not pointing to a practical implementable RFC.  I
am copying Michael and Paul (mentioned above) as one of them might be
willing to help with text.  I think this will greatly assist with the
deployability of session encryption.

Thank you!

-- 

Best regards,
Kathleen

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Apr 2017 11:19:18 -0400

> documenting the OS IPsec implementation for the Linux FreeS/WAN

it is RFC4322 actually.

We also tried to use DHCP(v4) to bootstrap IPsec for the last mile.
We didn't try to use IPsec to secure DHCP, but the mechanism that we
used would have permitted some interesting post-IP-address assignment
to work.

I haven't read dhc-sedhcpv6, but I might find time to do that so that
I understand the problem.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Lishan Li <[email-masked]>
Date: Thu, 20 Apr 2017 22:22:18 +0800

Hi, Kathleen,

Thanks a lot for your valuable comments on the draft. Please see inline.

Best Regards,
Lishan

2017-04-18 4:43 GMT+08:00 Kathleen Moriarty <kathleen.moriarty.ietf@gmail.

> Woulters is a author on the mentioned RFC and did implement this with
[LS]: In the before, we are just aware of the work of RFC7435 and not aware
of RFC7619. For the reference of RFC7619, I have one question and want to
get your guidance.
RFC7619 proposes the NULL authentication method for IPsec. If we add the
reference of RFC7619 for coffee shop scenario, then IPsec is used to
protect
the security of DHCPv6? Right?

However, our document defines the secure DHCPv6 mechanism, not using
the IPsec mechanism. If the IPsec mechanism is used, then the client and
Relay,
Relay and Relay, Relay and server need to establish the IPsec communication.
And for our document, we just want to protect the information between the
client
and server, so secure DHCPv6 is suited.

As opportunistic security for IPsec, our document proposes opportunistic
security
for DHCPv6. For the coffee shop, then the client and server can start the
NULL
authentication mode, which is easy to deployed.

Could you please help check whether my understanding correct? Looking
forward to
your further comments.

> deployability of session encryption.

[LS]: So, in our document, we need to states that: Opportunistic security
is mandatory to implement, not just say that opportunistic security can be
used for secure DHCPv6 deployment. Could you please help check whether
my understanding correct?

Thanks again,
Lishan