IETF Logo Mail Archive

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

"jouni.nospam" <jouni.nospam@gmail.com> Fri, 03 February 2017 21:21 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E78A12955A; Fri, 3 Feb 2017 13:21:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoeMQ0Dpb9T7; Fri, 3 Feb 2017 13:21:04 -0800 (PST)
Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264AE12955C; Fri, 3 Feb 2017 13:21:04 -0800 (PST)
Received: by mail-pf0-x244.google.com with SMTP id f144so2285433pfa.2; Fri, 03 Feb 2017 13:21:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pfEJMlRY2Mcj5WxL+uAuO8hZF+cfpD6oPUzeg7QQTcs=; b=Hcj7bvp4waOEWZUbFWL60bH1WFXGU/MPJ9IqLyK/YjQWad/k6y+UYDbzOmS/3EmHko f7CxrAYNDSNcgppN955zmiegOUqRdZfIQwp5Yi/drzuxT7zzXKpAoEcWKcHi3Z3JrLZ0 g4Mu5dhmRjsERiFTc4icgItgJ5qaen9aC/BNcHKG855a0H3LeWDJpj/NHKuY0WIiWCd0 d5HmBcklHy/UqMfPRMc2+CwPFJvSgP1UVuiUCJE5hq4RAatpa3uPxJT8S1Bb1p13Ghbt t1gPYHyeLA+P7YQK4m9Hc3Y50QBzfFqCjKo26UsYPwfnwdADL9oi37nUjoh99N+BkrTz c2fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pfEJMlRY2Mcj5WxL+uAuO8hZF+cfpD6oPUzeg7QQTcs=; b=iRlZXno8e7owqvzKtKuUUNByk02MCbE3O9+mvEgtjEP4tkHV5mDsg9qUYgEzY7YbDC p7nn0xHdL0AMjuaAe+1ZATl5AgNDzBKXHOfFbgEaqLHSZrYjcWeOtnatjlk3oeCOsGBk +nTONJEmLdb4Hp/J+4xdVPA9VZYGmSGITq5WZ9XgrkJhOMr5CSUgZOGaiIZEoS+NEc5n L5UMaFUhvVZlv5qhPsUd68NYCK6pEnuAazDP2pjlxjiCI2WRg5mWOl0D7/m6FA+fuo0O mG73zt0UVyTNTrYupFXBadzOASpEBHS8O7LMKbgNN5qdfi/s7k42/+4lvbV6A3Dn/o+R 25xw==
X-Gm-Message-State: AIkVDXL/HRrPiNDE/xNAPpfZt1MpYN4KSOzrNiFIRs4zpIAAS9Pd0hGXwf6/D1Tg9lz1Tw==
X-Received: by 10.84.173.4 with SMTP id o4mr24172926plb.106.1486156863695; Fri, 03 Feb 2017 13:21:03 -0800 (PST)
Received: from [192.168.89.94] ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id c204sm69321855pfb.51.2017.02.03.13.21.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 13:21:02 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: "jouni.nospam" <jouni.nospam@gmail.com>
In-Reply-To: <B9CFAC1C-F560-43F1-B50D-C0E2C56BF292@ericsson.com>
Date: Fri, 03 Feb 2017 13:21:00 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <28EBB7A8-92FB-4308-9413-CFF7F449A2AA@gmail.com>
References: <148541310715.6205.3276873953603821357.idtracker@ietfa.amsl.com> <ff898bc0-81ce-7598-c3f3-2e114d30df30@gmail.com> <e996599692ff4584b8ace30a36ea6881@XCH-ALN-003.cisco.com> <B3CE8C9D-C20C-4FAB-9054-0F09B2B87F63@gmail.com> <C099032E-F538-43AD-970F-F71A1A9E15D8@fugue.com> <367DE531-AF9C-40A3-8B1F-5F595D804023@gmail.com> <519FB5EF-52B0-4DEA-B670-2D2593C3FB66@fugue.com> <6DA7EAEF-C226-43E2-800A-9C3CB7F9FB6D@gmail.com> <B9CFAC1C-F560-43F1-B50D-C0E2C56BF292@ericsson.com>
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/y9_TyFLKt49Jhpm1iX-LoHL8LcY>
Cc: Bernie Volz <volz@cisco.com>, "int-dir@ietf.org" <int-dir@ietf.org>, Ted Lemon <mellon@fugue.com>, Jouni Korhonen <jounikor@gmail.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>, "draft-ietf-dhc-relay-server-security.all@ietf.org" <draft-ietf-dhc-relay-server-security.all@ietf.org>
Subject: Re: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Feb 2017 21:21:05 -0000

Suresh,

> On Feb 1, 2017, at 11:56 AM, Suresh Krishnan <suresh.krishnan@ericsson.com> wrote:
> 
> Hi Jouni,
>  Thanks for the review. 
> 
>> On Jan 27, 2017, at 3:20 PM, jouni.nospam <jouni.nospam@gmail.com> wrote:
>> 
>> 
>>> On Jan 26, 2017, at 11:27 AM, Ted Lemon <mellon@fugue.com> wrote:
>>> 
>>> On Jan 26, 2017, at 1:58 PM, jouni.nospam <jouni.nospam@gmail.com> wrote:
>>>> 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.
>>> 
>>> Okay, I see your point.   But suppose the document were changed so that rather than "updating" the document as you suggest, it simply referenced the sections in question and then made the SHOULDs into MUSTs that way?   Wouldn't that mean "implementations of this extension MUST," and wouldn't that be perfectly reasonable?
>>> 
>> 
>> 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).
> 
> I think the other two items in your review need to be fixed. But I have a slightly different take on this specific issue. In my view this document needs to stay on Standards track, and it should be made clear that it is an (optional) extension to RFC3315. This allows people who have implemented encryption for server-relay communications to claim compliance to RFC3315 and this document. For RFC3315bis, I think it should be discussed in the WG whether to mandate encryption or not as there are backward compatibility related considerations to be made.

I guess that works for me. In this case IMHO *-dhc-relay-server-security-* would be more of a profile for RFC3315 IPsec based security. I would find that useful.

Can you explain what is the real difference between extends vs. updates?

- Jouni

> 
> Regards
> Suresh
>

v2.23.0 | Report a Bug | By Email