Re: [Dime] Gen-art LC review of draft-ietf-dime-erp-12

Glen Zorn <glenzorn@gmail.com> Wed, 26 September 2012 01:03 UTC

Return-Path: <glenzorn@gmail.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A42721F8472; Tue, 25 Sep 2012 18:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.216
X-Spam-Level:
X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ub7qmI-aPwl; Tue, 25 Sep 2012 18:03:10 -0700 (PDT)
Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 762AE21F8425; Tue, 25 Sep 2012 18:03:10 -0700 (PDT)
Received: by danh15 with SMTP id h15so10769dan.31 for <multiple recipients>; Tue, 25 Sep 2012 18:03:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=nvhAs3Pg10fWPAU8MbM+lMbjkE+aYkedy9fhadOGw5o=; b=ILHvijeq3KI53TF8G71Sw7YzY/92UURIkmYWE4/oxwmNVHIm1mPbpMgA+QGa4gs/Kr 64YdAhi3ZmNVA8dnQb5XAjfw+4A9msTRYV49su7Wps6Y/dgGS18u71+iu/9qjNzfL/P9 QHMH/boIEGUUBjxufrlX2VONOzOnu3GPsygOTahXz5O4vYpCE8+cgRuUP4Y8kM9Wrhyy 3PkhQTpo6X1eRasu/eRJuCBys0SV5vCKbIRclwMuBwuojk2phazqmttzMGw7VLBTlxT2 hN1iaYpak31E8d9k68KhY7b/i7euWXG4twneJgZbzAJaDCOJNdoEVl3KBp/L9uzTfwFT zZPQ==
Received: by 10.68.189.164 with SMTP id gj4mr50287085pbc.48.1348621390179; Tue, 25 Sep 2012 18:03:10 -0700 (PDT)
Received: from [192.168.0.102] (ppp-124-120-227-192.revip2.asianet.co.th. [124.120.227.192]) by mx.google.com with ESMTPS id gf3sm1104098pbc.74.2012.09.25.18.03.06 (version=SSLv3 cipher=OTHER); Tue, 25 Sep 2012 18:03:09 -0700 (PDT)
Message-ID: <50625449.7010305@gmail.com>
Date: Wed, 26 Sep 2012 08:03:05 +0700
From: Glen Zorn <glenzorn@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120830 Thunderbird/15.0
MIME-Version: 1.0
To: Elwyn Davies <elwynd@dial.pipex.com>
References: <5060D8AB.8010807@dial.pipex.com>
In-Reply-To: <5060D8AB.8010807@dial.pipex.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "ietf@ietf.org" <ietf@ietf.org>, draft-ietf-dime-erp <draft-ietf-dime-erp@tools.ietf.org>, General Area Review Team <gen-art@ietf.org>, dime mailing list <dime@ietf.org>, draft-ietf-dime-erp.all@tools.ietf.org
Subject: Re: [Dime] Gen-art LC review of draft-ietf-dime-erp-12
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Sep 2012 01:03:11 -0000

On 09/25/2012 05:03 AM, Elwyn Davies wrote:

> Gen-art LC review of  draft-ietf-dime-erp-12 I am the assigned Gen-ART
 > reviewer for this draft. For background on Gen-ART, please see the
 > FAQ at
 >
 > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
 >
 > Please resolve these comments along with any other Last Call
 > comments you may receive.
 >
 > Document: draft-ietf-dime-erp-12.txt Reviewer: Elwyn Davies Review
 > Date: 24 September 2012 IETF LC End Date: 24 September 2012 IESG
 > Telechat date: (if known) -
 >
 > Summary: Almost ready for the IESG. There are some minor wording
 > issues to sort out in s3, some advice on advertising domain names in
 > s5 and possibly some extra words needed in the security
 > considerations. In addition there a few minor nits.
 >
 > Major issues: None.
 >
 > Minor issues: s3: Both paragraphs use the phrase '...document assumes
 > the existence of at most one...'. Does this really mean 'exactly
 > one'?

Oddly enough, it means just what it says.

> If not, what happens if there  is exactly zero servers for either
 > type?

Both protocols will fail gracefully.

> What would the consequences of  there being more than one
 > logical server?

If the message is directed to a logical server not in possession of the 
rRK or rDSRK (depending upon where the server is located), ERP will fail 
inappropriately.

> Is this tied into the statement  in s4:
 > The ER server is located either in the home domain (same as EAP
 > server) or in the visited domain (same as authenticator, when it
 > differs from the home domain).

I don't think so.

> This would seem to imply that  the zero case means that it may not be
 > essential to have an ER server in a domain.

It's not.

>
 > S3, para 1:
 >> If multiple ER servers are deployed in the domain, we assume that
 >> they can be used interchangeably.
 > Are we talking physical servers here?

Yes.

> If not please refer to the
 > previous comment.
 >
 > s5, para 1: How would the authenticator advertise the domain name in
 > this context?

That is outside the scope of this draft.

>
 > s13: Looking at the various security considerations that are
 > imported, I wondered if some extra words were needed in respect of a
 > couple of the cases: - s8.4 of RFC 4072: (does distributing the
 > bootstrapping master key make things any worse here?) -

I don't think so.

> s8 of RFC
 > 6696 (does the DIME usage preserve the limited key scope?; is the
 > domino effect equally well avoided?)

Yes and yes.

>
 > Nits/editorial comments:
 >
 > s1: 'and re-use the Diameter EAP commands (DER/DEA).' : DER and DEA
 > ought to be expanded here. Or it might be less verbose to point at s2
 > where they are currently expanded, thus: 'and re-use the Diameter EAP
 > commands listed in Section 2.'

These are both defined in RFC 4072.

>
 > s2, para 2: Need to expand acronyms rRK and rDSRK.

rRK is defined in RFC 6696.

>
 > s4, para 7: Should explicitly say that the ERP/DEA message is sent to
 > the authenticator.

It's not: the authenticator is an EAP protocol entity.  The message is 
sent to the Diameter peer, like all Diameter answer messages.

>
 > s8.3.3: s/RGC 6696/RFC 6696/
 >
 >

Fixed, thanks.