Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-server-security-01.txt

From: [email-masked]
Date: Mon, 17 Oct 2016 06:53:41 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration of the IETF.

        Title           : Security of Messages Exchanged Between Servers and Relay Agents
        Authors         : Bernie Volz
                          Yogendra Pal
	Filename        : draft-ietf-dhc-relay-server-security-01.txt
	Pages           : 8
	Date            : 2016-10-17

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-relay-server-security/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dhc-relay-server-security-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-relay-server-security-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 17 Oct 2016 13:57:33 +0000

Hi:

This update was a very minor change suggested by Stephen Farrell. In section 3, the last sentence in the 1st paragraph was updated to add "and other attacks", since this not only protects against pervasive monitoring.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 17, 2016 9:54 AM
To: [email-masked]
Cc: [email-masked]
Subject: [dhcwg] I-D Action: draft-ietf-dhc-relay-server-security-01.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 17 Oct 2016 16:48:36 +0000

Hi Bernie,

Just so I can understand the intent of this document, if the relay(s) and server
already know that some form of encryption is already in use (e.g., if the client
and server are using sedhcpv6) then it should be OK to omit encryption between
the Relay and Server. Does this draft intend to mandate the use of encryption
in all cases?

Thanks - Fred

> From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
> Sent: Monday, October 17, 2016 6:58 AM
> To: [email-masked]
> Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-relay-server-security-01.txt
> 
> Hi:
> 
> This update was a very minor change suggested by Stephen Farrell. In section 3, the last sentence in the 1st paragraph was updated to
> add "and other attacks", since this not only protects against pervasive monitoring.
> 
> - Bernie
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 17 Oct 2016 17:17:27 +0000

Hi:

As stated in Section 3:

   While IPsec is not mandated for relay to relay, relay to server, and
   server to relay communication, it is highly recommended unless some
   other security mechanisms are already in place (such as VPN tunnels)
   that protect this potentially sensitive traffic from pervasive
   monitoring and other attacks.

It doesn't mandate anything but highly recommends it. Yes, this is "weak" and really leaves it for the operator to decide what is necessary in their deployment. (One thought is that if someone is able to get into that part of the network, there is probably a lot more that they can do and monitor ... and just protecting they relay/relay/server communication is only one small piece).

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Monday, October 17, 2016 12:49 PM
To: Bernie Volz (volz) <[email-masked]>; [email-masked]
Subject: RE: [dhcwg] I-D Action: draft-ietf-dhc-relay-server-security-01.txt

Hi Bernie,

Just so I can understand the intent of this document, if the relay(s) and server already know that some form of encryption is already in use (e.g., if the client and server are using sedhcpv6) then it should be OK to omit encryption between the Relay and Server. Does this draft intend to mandate the use of encryption in all cases?

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 17 Oct 2016 20:35:08 +0000

Hi Bernie,

> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Monday, October 17, 2016 10:17 AM
> To: Templin, Fred L <[email-masked]>; [email-masked]
> It doesn't mandate anything but highly recommends it. Yes, this is "weak" and really leaves it for the operator to decide what is
> necessary in their deployment. (One thought is that if someone is able to get into that part of the network, there is probably a lot
> more that they can do and monitor ... and just protecting they relay/relay/server communication is only one small piece).

That being the case, I am good with it.

Thanks - Fred
[email-masked]

> Just so I can understand the intent of this document, if the relay(s) and server already know that some form of encryption is already in
> use (e.g., if the client and server are using sedhcpv6) then it should be OK to omit encryption between the Relay and Server. Does this
> draft intend to mandate the use of encryption in all cases?
> 
> Thanks - Fred
>

---

From: yogendra pal <[email-masked]>
Date: Thu, 20 Oct 2016 00:30:47 +0530

DHC wg,

As a co-author of this draft, I and Bernie believe this document is ready
for WGLC. I would request
working group chair/AD to call for WGLC on this draft.

Best Regards,
Yogendra Pal

On Tue, Oct 18, 2016 at 2:05 AM, Templin, Fred L <[email-masked]>
wrote:

> > It doesn't mandate anything but highly recommends it. Yes, this is
> "weak" and really leaves it for the operator to decide what is
> > necessary in their deployment. (One thought is that if someone is able
> to get into that part of the network, there is probably a lot
> > more that they can do and monitor ... and just protecting they
> relay/relay/server communication is only one small piece).
>
> > Just so I can understand the intent of this document, if the relay(s)
> and server already know that some form of encryption is already in
> > use (e.g., if the client and server are using sedhcpv6) then it should
> be OK to omit encryption between the Relay and Server. Does this

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 26 Oct 2016 21:19:11 +0200

Hi,
Authors believe this draft to be ready for working group last call.
Please send your substantial comments to the mailing list and express
your opinion whether this draft is ready for publication. Feel free to
send nitpicks and minor corrections to the authors directly.

This draft has been adopted relatively recently. It's a very short draft
(a bit over 3 pages of the actual text) that explains how communication
between relays and servers could be secured using IPSec.
The issue it tries to address was raised during IESG discussions couple
months ago when processing one of the earlier DHC drafts.

Please post your comments by Nov. 9th. Since Bernie is a co-author, I
will determine the consensus.

Title: Security of Messages Exchanged Between Servers and Relay Agents
Authors: Bernie Volz, Yogendra Pal
Filename: draft-ietf-dhc-relay-server-security-01
Pages: 8
Date: 2016-10-17

Thanks,
Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 28 Oct 2016 21:57:40 +0000

Hi:

As a co-author, I support this moving forward.

During the WGLC draft-ietf-dhc-rfc3315bis-05, Jinmei raised a comment regarding Key Management in section 19.1 of that bis document  (see (https://www.ietf.org/mail-archive/web/dhcwg/current/msg17577.html) that also impacts the text in this new draft.

After some offline exchanges, I propose we change the text for Key Management in section 3 of the this document (and similarly in the bis document) to:

   Key management          Because both relay agents and servers tend to
                           be managed by a single organizational entity,
                           public key schemes may be optional.  Manually
                           configured key management may suffice, but
                           does not provide defense against replayed
                           messages.  Accordingly, IKE [RFC2409] / IKE2
                           [RFC7296] with preshared secrets SHOULD be
                           supported.  IKE/IKEv2 with public keys MAY be
                           supported.  Additional information on manual
                           vs automated key management and when one
                           should be used over the other can be found in
                           [RFC4107].

- Bernie

-----Original Message-----
From: Tomek Mrugalski [mailto:[email-masked]] 
Sent: Wednesday, October 26, 2016 3:19 PM
To: [email-masked]
Cc: Yogendra Pal <[email-masked]>; Bernie Volz (volz) <[email-masked]>
Subject: WGLC on draft-ietf-dhc-relay-server-security-01 - respond by Nov 9

Hi,
Authors believe this draft to be ready for working group last call.
Please send your substantial comments to the mailing list and express your opinion whether this draft is ready for publication. Feel free to send nitpicks and minor corrections to the authors directly.

This draft has been adopted relatively recently. It's a very short draft (a bit over 3 pages of the actual text) that explains how communication between relays and servers could be secured using IPSec.
The issue it tries to address was raised during IESG discussions couple months ago when processing one of the earlier DHC drafts.

Please post your comments by Nov. 9th. Since Bernie is a co-author, I will determine the consensus.

Thanks,
Tomek