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

"Bernie Volz (volz)" <> Thu, 26 January 2017 19:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C47F1299AD; Thu, 26 Jan 2017 11:18:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.72
X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ndmJ1COfNDII; Thu, 26 Jan 2017 11:18:11 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3973F129992; Thu, 26 Jan 2017 11:18:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3294; q=dns/txt; s=iport; t=1485458291; x=1486667891; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=j0dL5zsaMHfEVK9dwPOuj0hzsOEUkp4yaWbQf6OK4pk=; b=c2Lp0l34wo8qcRWNxPpQGFqxMscpGKLJJsLS6J5mm7a9nQvkfWcXURgq vEs0/nIt73ltqCCOT/kZ49QeCKfy1Nx82BDbBfU2ldbCiLRzlW9yRSYdT rPyrl3krRnmpTNbY1wOmSLhwMz7WovpQDleiSoNAVzjWeUk8Bbnpr60Rc Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.33,290,1477958400"; d="scan'208";a="200574266"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2017 19:18:10 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v0QJIANi015240 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 26 Jan 2017 19:18:10 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 26 Jan 2017 13:18:09 -0600
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Thu, 26 Jan 2017 13:18:09 -0600
From: "Bernie Volz (volz)" <>
To: "jouni.nospam" <>, Ted Lemon <>
Subject: RE: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02
Thread-Topic: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02
Thread-Index: AQHSd5+8iSisaOl5IUWbOnwv5FiO+aFK8haA///OnZCAALfagIAAAyOAgAAGBgD//5wlwA==
Date: Thu, 26 Jan 2017 19:18:09 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Thu, 26 Jan 2017 19:18:13 -0000


It sounds like we should not use:

"The following text replaces the text in RFC3315 section 21.1 ..."

But instead just use something close to the following which replaces 1st paragraph in section 3:

   For DHCPv6 [RFC3315], this specification REQUIRES IPsec encryption of relay to
   relay and relay to server communication.

   For DHCPv4 [RFC2131], this specification REQUIRES IPsec encryption of relay to
   server communication.

   By using IPsec with encryption for this communication,  the potentially sensitive
   client message and relay included information, such as the DHCPv4 relay-agent
   information option (82), vendor-specific information (for example, [CableLabs-DHCP]),
   and Access-Network-Identifier Option(s) [RFC7839], are protected from pervasive
   monitoring and other attacks.

What is in other documents doesn't really matter ...

- Bernie

-----Original Message-----
From: jouni.nospam [] 
Sent: Thursday, January 26, 2017 1:59 PM
To: Ted Lemon <>
Cc: Bernie Volz (volz) <>; Tomek Mrugalski <>;;;; Jouni Korhonen <>;
Subject: Re: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02

> On Jan 26, 2017, at 10:36 AM, Ted Lemon <> wrote:
> On Jan 26, 2017, at 1:25 PM, jouni.nospam <> wrote:
>> Hmm.. I really do not like specification “games” like this. If you cannot justify a MUST into RFC3315bis, then trying to circumvent the fact in another document (that does not update the RFC3315 or RFC3315bis) should not be a Standards Track document. I could accept this as a BCP or a like.
> Hm, then you are saying that every extension ever done to a protocol that, if it contains MUSTs, MUST update that protocol, even if implementations that support the extension can interoperate with implementations that do not and vice versa.   What’s your basis for this?

No. But in this case there are pieces of text that change specific places in the original document from SHOULDs to MUSTs, musts to MUSTs, and adds few pieces of new stuff, etc. Now how that in not updating? Changes or “extensions” like that would be nice to follow from the base document.

- Jouni