Re: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02

"jouni.nospam" <> Mon, 30 January 2017 22:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12A9A129C07; Mon, 30 Jan 2017 14:20:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3NVlY_7mBVWg; Mon, 30 Jan 2017 14:20:09 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC2B2129C06; Mon, 30 Jan 2017 14:20:06 -0800 (PST)
Received: by with SMTP id 19so24359862pfo.3; Mon, 30 Jan 2017 14:20:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J5/u/wXPP4X5vQAOYHdCZ9RjUZsm5BYOp8m56BhJpDc=; b=pyva9aDO6MygEfObe/SZt6Q35FubyhEbuHbXzvOM/yY5vMfViesceTMfzBmqABFX20 Wge0aKZUhhWv1+VD+WLkdOznzSX0HJu26tMY6s9IH85qsvzZJBG50F9o4uhgMKCwipuI +YIIx3Bfu/IFi7TQ/0Muanb/dLcZUXG+w73kbp3u2h91CboGXldAJ8jBKnTqd9tkf4KU UvvVfUjsC9KBF6zt/8cfUHSJZkgjvOKOizs5EeL7ugjvkh7yYXrsnTBJEX8ZoMdaRwRI oMtj5Cjq2U3IyUbGiVyxQ1ul1haM6HPPfIaRJYktPEPoyyvFtdrljHZ7J9lkwBdlH43F hQ8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J5/u/wXPP4X5vQAOYHdCZ9RjUZsm5BYOp8m56BhJpDc=; b=f38B0I+52Tz5XbYe3lXI+MqgsbHelxnRs5vbh5L6BkiLsHkvn5Vtu3vzS9qx0hN0Cz TCSpnrITaOZ7lOjqo9FFcJDRNER3K5GCwSrGQkj+5+5dIucrfbrNCvuijVhzyxvdIDLe Q7V1fBOuElY9FmC1+cVaOE6lg7S3DGWZHtxLSaNVNL7cbaicMmJkzGHfk3mXBZjznSbj nkU19hDxP69T/8wpaWW2bDgyTGwefAPtUBiXFKTUqKN8fgrDAbzfs9WyILmCkM4RDZhG KL0plXEJESQa/vVBiLoahAdzDVONFB7zKC1ltvd0hOvaowuOpgA+2rkJOxf9r9woguXv pxhw==
X-Gm-Message-State: AIkVDXK/p6MeVLlNRoKibadqvCWHHxUc/7+LnZj/npuqmyKbRAhprQZQJB7Z5L8VcUHtZQ==
X-Received: by with SMTP id z21mr26635610pgn.187.1485814806154; Mon, 30 Jan 2017 14:20:06 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id j28sm35080355pfj.2.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 14:20:04 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02
From: "jouni.nospam" <>
In-Reply-To: <>
Date: Mon, 30 Jan 2017 14:20:02 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Ted Lemon <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: "" <>, "" <>, Tomek Mrugalski <>, Jouni Korhonen <>, "" <>, "" <>
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: Mon, 30 Jan 2017 22:20:11 -0000


> On Jan 27, 2017, at 1:25 PM, Ted Lemon <> wrote:
> On Jan 27, 2017, at 3:20 PM, jouni.nospam <> wrote:
>> I would still argue that it updates specifically if the document here is going to be standards track. If this document here would be more of a recommendation e.g., BCP I would be fine without the “updating” part (as I remember the MUST for IPsec in RFC3315bis was not endorsed by the WG).
> Ok, but it's not a BCP, it's a standard, with requirements for interop.   So it can't be a BCP.
> Given that it can't be a BCP, the other choices are "informational" and "experimental" and "updates the base spec."   You are saying that you want "updates the base spec," which would mean that everybody would have to implement it to conform to the new, updated spec.   But the argument has been made that this is not desirable: not everybody needs to implement this, and it is not desired that implementing this be a requirement.

The main differences in relay-server-security compared to rfc3315bis are:
1) the addition of mandatory to implement encryption and authentication algorithms
2) removal of IKEv1
3) removal of the availability statement
4) mixing IPv4 there as well

Otherwise it is mainly about capitalizing rfc2119 keywords (well one should changes to MUST, and one ’use’ is preceded with a MUST).

Now if I decide to implement rfc3315bis *with* security, follow all musts in Section 20.1, and listed “updates” in the header, I have still no guarantee whether I can interoperate with another rfc3315bis implementation because it decided to follow relay-server-security. That is not good.

> So are you saying that you disagree with this—that you think it should be MTI?   Or are you saying that there is some other way to accomplish this goal?

I am saying.. the intention of relay-server-security is good and I support it. The way it is done is IMHO not good. What I would do is to fix Section 20.1 in rfc3315bis with proper rfc2119 keywords and missing pieces (like the algorithms), but still keeping the implementation of 20.1 optional as it is now. Then I would do (i.e., relay-server-security) as a BCP saying “implementation of the security in rfc3315bis as defined in Section 20.1 is REQUIRED and MUST use the following profile..”. This can be worded to cover both DHCPv4 and DHCPv6.

- Jouni