Review of draft-ietf-dhc-relay-server-security-02

Jouni Korhonen <> Thu, 26 January 2017 06:45 UTC

Return-Path: <>
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 26947129497; Wed, 25 Jan 2017 22:45:07 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Jouni Korhonen <>
Subject: Review of draft-ietf-dhc-relay-server-security-02
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <>
Date: Wed, 25 Jan 2017 22:45:07 -0800
Archived-At: <>
X-Mailman-Version: 2.1.17
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Jan 2017 06:45:07 -0000

Reviewer: Jouni Korhonen
Review result: Not Ready

Disclaimer: I have not followed recent DHC discussions to the extent
that the existence this document was new to me.


My issues with the document are the following. First, it actually
updates a great deal of RFC3315 (Section 21.1) while there is
RFC3315bis in progress. Why the DHCPv6 part of this document is not
directly contributed to RFC3315bis work? There's even author overlap
so there must be a good reason. Second, if there is a reason to keep
the content of this document separate from RFC3315 body of work, at
least this specification should then target to update RFC3315bis and
not RFC3315.

Other smaller nits:

o This document updates both RFC3315(bis) and RFC1542. Those are not
reflected in the document title page and abstract. 

o I would separate the new recommendation text for DHCPv4 and DHCPv6
into their own respective section. Having just a one-liner statement
"also applies to DHCPv4 [RFC1542].." is kind of confusing in a middle
of very DHCPv6 specific text. I recon the DHCPv4 section would be
short, but definitely more clear in that way.

o Although it should be obvious, but I would explicitly point it out
in the Security Considerations that the security model here is
hop-by-hop. If there are multiple relays then there will be multiple
IPsec tunnels as well.

o Section 14:  s/section 14,/Section 14,