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

"Yogendra Pal (yogpal)" <> Tue, 31 January 2017 18:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D75F129546; Tue, 31 Jan 2017 10:38:27 -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, HTML_MESSAGE=0.001, 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, 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 rv8Ur1j_I1GZ; Tue, 31 Jan 2017 10:38:24 -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 61EA4129447; Tue, 31 Jan 2017 10:38:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=19278; q=dns/txt; s=iport; t=1485887904; x=1487097504; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vDqkMJwgR7RLr1gSCZpM4t/oHk4ZdhnESvmJZAh+vYo=; b=WdaPy99lDqcJj5Bd/w8ZvKN4cxLd6U6pMZmunrfZsCOigYGajswXOSRz TvxNVj0DirXxgkoK8bcwe01WKtvxr14DvwzOppnkL61gBKfFhXjccCecl NuJ6SMnKvW+mUAmFJhBx49SdrRwdV5d8het/d10Se/1tQqeppZl5EAl0p I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.33,315,1477958400"; d="scan'208,217";a="200972974"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Jan 2017 18:38:22 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v0VIcMlv003752 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 31 Jan 2017 18:38:22 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 31 Jan 2017 12:38:22 -0600
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Tue, 31 Jan 2017 12:38:21 -0600
From: "Yogendra Pal (yogpal)" <>
To: "Bernie Volz (volz)" <>, Ted Lemon <>, "jouni.nospam" <>
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
Date: Tue, 31 Jan 2017 18:38:21 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D4B6CD1221668yogpalciscocom_"
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: Tue, 31 Jan 2017 18:38:27 -0000

With full due respect of conversation, I see Bernie's point, towards flexibility. For e.g: We see two operators primary wherein, device operator would like to have base RFC3315 supported for n/w and security operator asking for security in n/w via RFC9999.

Regards, Yogendra Pal
From: "Bernie Volz (volz)" <<>>
Date: Tuesday, 31 January 2017 4:38 am
To: Ted Lemon <<>>, "jouni.nospam" <<>>
Cc: Tomek Mrugalski <<>>, "<>" <<>>, "<>" <<>>, "<>" <<>>, Jouni Korhonen <<>>, "<>" <<>>
Subject: RE: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02
Resent-From: <<>>
Resent-To: <<>>, Yogendra Pal <<>>, <<>>, <<>>, <<>>, Tomek Mrugalski <<>>
Resent-Date: Tuesday, 31 January 2017 4:39 am


Let's take the 3315bis out of the discussion as we don't yet know when that will be available and we'd like to progress on this draft sooner than that (as it is shorter and easier to do). We can get back to it later, but let's focus first on today's issue with is the document with RFC 3315.

So if this is released as RFC9999, the only way you as someone looking for relay or server implementations (or both) could know that this is supported is by asking the supplier whether they support RFC3315 and RFC9999. RFC9999 does not have up update 3315. This is just like many of the other DHCP RFCs which extend the functionality - Leasequery, bulk Leasequery, active Leasequery, and the many options documents. If you want certain features and they are in other documents, you have to specify the complete list.

Saying it updates RFC3315 doesn't help since there are plenty of existing implementations that don't support IPsec.

Back to RFC 3315 bis (draft-ietf-dhc-rfc3315bis), that is still a work in progress. Our plans to date are that we'll incorporate all of the changes of draft-ietf-dhc-relay-server-security but leave it OPTIONAL to implement IPsec. This means that once draft-ietf-dhc-rfc3315bis is published as an RFC, those that want IPsec will have to check that the implementation supports both the bis RFC and RFC9999 (or whatever number). But that's the same that someone wanting Leasequery must do - they'll need to check that the bis RFC and RFC5007 are supported.

The draft-ietf-dhc-rfc3315bis and/or draft-ietf-dhc-relay-server-security authors can always raise it to the DHC WG to see if there is sufficient consensus to make IPsec a MUST in the bis document. But there hasn't been in the past.

-          Bernie

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

On Jan 30, 2017, at 5:20 PM, jouni.nospam <<>> wrote:
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.

Thanks.   This is the clarification I was looking for.