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

Tomek Mrugalski <> Thu, 26 January 2017 10:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 51388129517; Thu, 26 Jan 2017 02:24:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ab2mB-KPmrJC; Thu, 26 Jan 2017 02:24:36 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 39B42129448; Thu, 26 Jan 2017 02:24:33 -0800 (PST)
Received: by with SMTP id c206so76080523wme.0; Thu, 26 Jan 2017 02:24:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=caoNdxm3lAOM6RKt3LPMOnP8x4nt4GkHlhD26IMyUUY=; b=dDhWG+EnmYibULKRq0d3v+DN4hM0g4MFQwjteZR5hGOauX6LKKA11zZfuw4f2JsXqO HzSw+XpXAssLcZLhnquwnxvEFiV2uNd1qxO3AU3vepTvoSBg7Yo8WIGkxdr8fLUwkbs8 u/ElaZDES+frLHgp0AdP2SsbtJW5DR2fe3w/wflNWCoCGUmkAXK9N2+4tuhdwSDSESEJ JFDKO8sGjgxnlLZv35ueMx0Y7b7WINAIJ35lf6r8bcixuo1aloHePavLPpdbC3FvUUdt 2hG56pkCN1HCgFq4jamaOcVxRobxtz5gWsObLPtPETYel/faz/b+fivWjGPyuAo+u46Z 8pIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=caoNdxm3lAOM6RKt3LPMOnP8x4nt4GkHlhD26IMyUUY=; b=Tlw3dcSjzEp18TPsl7C7HavMdHqRySLQtRWASRZO1Nvf9r1/brkFYpt5F+8PmCgNid B5vUNUwIR/kTSj/28dcCSxZAo1l0pvJwUyzemk09yisWGYf+Cd+6+mYgrW3GIpajZ33u 0UYYPLYOUErsAoC3MpOBOTt+4hBmZnvNX+BUg4wocbD0OCxVevGzQRerfW4uLcgsU9gq hr6Q1KwhhtHC+tWi9KOcImyqPTgBfsMlas9FmskV/U1WkQHSKoyVlCX5nBW/TUBS5HX+ 18Oqw6UMsuf9SqZWJm3n8FDz3/GzyrzwZay94Ykw6EtN11avXFt093b7HbYQbleZ0SP1 ZiAQ==
X-Gm-Message-State: AIkVDXJ8EnnjXMqN3/tufYdDqScx9ffAvfg6apFIiK656cmUKHl1yXuEPgpX8lpUO0A6zg==
X-Received: by with SMTP id 90mr1974863wri.156.1485426271373; Thu, 26 Jan 2017 02:24:31 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id 33sm1791516wrd.34.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 02:24:30 -0800 (PST)
Subject: Re: Review of draft-ietf-dhc-relay-server-security-02
To: Jouni Korhonen <>,
References: <>
From: Tomek Mrugalski <>
Message-ID: <>
Date: Thu, 26 Jan 2017 11:24:29 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Jan 2017 10:24:37 -0000

W dniu 26.01.2017 o 07:45, Jouni Korhonen pisze:
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.
Hi Jouni,
First of all, thanks for doing the review.

I will leave it up to the authors to provide further details on this, but with my shepherd hat on, let me explain that this omission was made on purpose. The decision was made to not update 3315 and not bundle this into 3315bis on purpose. If we did that, then every DHCP server would HAVE to support IPSec. This would make implementation, certification and deployment much more complex and this is something we wanted to avoid. With the current approach, operators can be specific whether they need relay server security (by requiring their vendors to support both 3315 and this document) or not (just 3315).

This is also explained in the write-up:
(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No. Even though this I-D introduces changes to RFC3315, the WG doesn't
  want to enforce IPsec encryption on every DHCPv6 server. Therefore
  it does not update RFC3315.

Also, I'd like to clarify that 3315bis is not a wildcard that bundles every RFC related to DHCPv6 ever published. This document is 133 pages long and that size causes difficulties moving the work forward. We're thinking what are the things we can take out of it, rather what else we could add. The previous argument still stands here. We want to have the core spec and an additional RFC that people can point to when they require secure server-relay communication.

If that explanation is not acceptable for you, how do you propose to structure the text and possibly add updates 2131/3315 to achieve the goal or being a non-mandatory feature?

I'll let the authors comment on the nits.

Again, thanks for the review. It's good to receive one that shakes things up a bit once in a while :)
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,