Subject: [dhcwg] Submitted draft-volz-dhc-relay-server-security-00.txt

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 20 Apr 2016 13:11:16 +0000

Hi:

I just submitted a new (individual submission) Internet-Draft to address relay/server exchanges and pervasive monitoring, as I mentioned at IETF-95 - see https://www.ietf.org/proceedings/95/slides/slides-95-dhc-3.pdf.

Please look at the draft and comment to the list.

Thanks.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, April 20, 2016 9:08 AM
Subject: New Version Notification for draft-volz-dhc-relay-server-security-00.txt

A new version of I-D, draft-volz-dhc-relay-server-security-00.txt
has been successfully submitted by Bernie Volz and posted to the IETF repository.

Name:		draft-volz-dhc-relay-server-security
Revision:	00
Title:		Security of Messages Exchanged Between Servers and Relay Agents
Document date:	2016-04-20
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/internet-drafts/draft-volz-dhc-relay-server-security-00.txt
Status:         https://datatracker.ietf.org/doc/draft-volz-dhc-relay-server-security/
Htmlized:       https://tools.ietf.org/html/draft-volz-dhc-relay-server-security-00

Abstract:
   The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no
   guidance for how to secure messages exchanged between servers and
   relay agents.  The Dynamic Host Configuration Protocol for IPv6
   (DHCPv6) states that IPsec should be used to secure messages
   exchanged between servers and relay agents, but does not recommend
   encryption.  And, with recent concerns about pervasive monitoring it
   is appropriate to provide recommendations for DHCPv4 and also improve
   the recommendations for DHCPv6.  This document updates RFC1542 and
   RFC3315.

---

From: 神明達哉 <[email-masked]>
Date: Mon, 25 Apr 2016 11:12:01 -0700

At Wed, 20 Apr 2016 13:11:16 +0000,

> Please look at the draft and comment to the list.

It generally looks good to me.  One thing I'd suggest is to explain
why explicit confidentially is needed for relay-to-relay or
relay-to-server in a bit more detail.  This point will matter more for
DHCPv6 as we are going to introduce end-to-end (i.e., client-to-server
possibly via relays) encryption into DHCPv6 (I-D.ietf-dhc-sedhcpv6).
volz-dhc-relay-server-security refers to the sedhcpv6 I-D, but it
doesn't explain why we still need to introduce relay-to-relay
encryption.  From slides-95-dhc-3, I guess this is mainly because
(among other things like whether sedhcpv6 is ever really deployed)
some information that can't be covered in client-to-server
confidentiality can still be privacy sensitive, like in the case of
access-network-identifier (which makes sense to me).  I think it would
be better for volz-dhc-relay-server-security to explain this
background explicitly.

--
JINMEI, Tatuya

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 25 Apr 2016 19:02:02 +0000

Hi Jinmei:

Sounds reasonable. I'll plan to incorporate this change into the next version.

How about replacing the "This revised text essentially adds encryption." sentence in section 3 with:

"This revised text essentially adds encryption as relay agents may forward unencrypted client messages as well as include additional information, such as vendor-specific information (for example, [CableLabs]) and [RFC7839]."

Note that [CableLabs] reference would be to CableLabs’ DHCP Options Registry (http://www.cablelabs.com/specification/cablelabs-dhcp-options-registry-2/) and [RFC7839] is the to-be draft-ietf-dhc-access-network-identifier-13.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ????
Sent: Monday, April 25, 2016 2:12 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]
Subject: Re: [dhcwg] Submitted draft-volz-dhc-relay-server-security-00.txt

> Please look at the draft and comment to the list.

It generally looks good to me.  One thing I'd suggest is to explain why explicit confidentially is needed for relay-to-relay or relay-to-server in a bit more detail.  This point will matter more for
DHCPv6 as we are going to introduce end-to-end (i.e., client-to-server possibly via relays) encryption into DHCPv6 (I-D.ietf-dhc-sedhcpv6).
volz-dhc-relay-server-security refers to the sedhcpv6 I-D, but it doesn't explain why we still need to introduce relay-to-relay encryption.  From slides-95-dhc-3, I guess this is mainly because (among other things like whether sedhcpv6 is ever really deployed) some information that can't be covered in client-to-server confidentiality can still be privacy sensitive, like in the case of access-network-identifier (which makes sense to me).  I think it would be better for volz-dhc-relay-server-security to explain this background explicitly.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Mon, 25 Apr 2016 13:28:53 -0700

At Mon, 25 Apr 2016 19:02:02 +0000,

> "This revised text essentially adds encryption as relay agents may forward unencrypted client messages as well as include additional information, such as vendor-specific information (for example, […

Works for me.

--
JINMEI, Tatuya