[Gen-art] Gen-ART review of draft-ietf-radext-dynamic-discovery-13

Martin Thomson <martin.thomson@gmail.com> Sat, 21 March 2015 17:52 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id DBF021ACCD9 for <gen-art@ietfa.amsl.com>; Sat, 21 Mar 2015 10:52:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nX-UvOY6c9gJ for <gen-art@ietfa.amsl.com>; Sat, 21 Mar 2015 10:52:02 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 1FE3F1ABD3F for <gen-art@ietf.org>; Sat, 21 Mar 2015 10:52:02 -0700 (PDT)
Received: by oier21 with SMTP id r21so113788126oie.1 for <gen-art@ietf.org>; Sat, 21 Mar 2015 10:52:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TlwHyEy+6c43pPvmN/n5EHrPc77xCpLrcOxCUPl72zU=; b=s7ZLlQvrqxEBNNOczV8tR+71bDy0ENvBIn4ZpA5672MWdod1C2n83+8xFeVLBmQiDO 5F1h4CKG7+KUcitUXVVlt29k839biK8JCYRjbEf0BVHdCL1JKIkY2rxDUXZqO6/IQedg hXe6lDa1jUq5xjrruRVuFFLwpiS5Phfk57WNPxNdYKzzUIvbP4luUzU6AK3wrG4FpQTb shd/jSuzZbY2N8S6JrPlKuVgiaa8vLz+xI9nVfF68zqHyRknEkSZmZnL510kBOoAYG9k NN4TnLvngylUZEV+ro2Vhw3IGXKFnVm9rK8X5NiOCEE6wm6hL/5Ac7mMup84qBH9jY5V b5rA==
MIME-Version: 1.0
X-Received: by with SMTP id mw5mr70549370obc.26.1426960321686; Sat, 21 Mar 2015 10:52:01 -0700 (PDT)
Received: by with HTTP; Sat, 21 Mar 2015 10:52:01 -0700 (PDT)
Date: Sat, 21 Mar 2015 10:52:01 -0700
Message-ID: <CABkgnnVfD1nHgS78ys38XdEd09Wf5hSRz1dkACRi4X4roVz1Cw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "gen-art@ietf.org" <gen-art@ietf.org>, draft-ietf-radext-dynamic-discovery.all@tools.ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/WKAxdpgIwRHshAr81JF9R1f_hYk>
Subject: [Gen-art] Gen-ART review of draft-ietf-radext-dynamic-discovery-13
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Mar 2015 17:52:04 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-radext-dynamic-discovery-13
Reviewer: Martin Thomson
Review Date: 2015-03-21
IETF LC End Date: 2015-03-20
IESG Telechat date: 2015-04-19

Summary: This document is of a quality I rarely see even for proposed
standard.  It is certainly fit for publication as an experimental RFC.
(In case it isn't clear, I agree with the decision to choose
experimental here, this is in a tricky area and deployment experience
will validate choices.)

Major issues: None

Minor issues:

S-NAPTR tags for RADIUS are defined, but none for Diameter.  I'm sure
this was considered, but it seems odd on first reading.

S2.1.1.2 uses SHOULD to recommend that clients retry with their other
certificates.  I'd recommend use of MAY here, unless you would like to
expand on why this a SHOULD is valuable.

S2. I know that this is experimental and all, but this seems a
little too hand-wavy even for that.  I think that this is the right
design, but the section could be a little more confident (and precise)
in the description of how this works.  It took me a couple of goes to
understand how this was intended to work.  One important realization
was that a common root for the realm needs to be configured.  I'd like
to see this section expanded slightly (my initial inclination would
have been toward removal, but the content is in line with the
experiment, so it's probably valuable).

S2.2 says:
   Since the Domain Name System is not
   necessarily trustworthy (e.g. if DNSSEC is not deployed for the
   queried domain name), it is important to verify that the server which
   was contacted is authorized to service requests for the user which
   triggered the discovery process.

This implies that DNS integrity is the only reason for authentication.
To paraphrase Steve Bellovin: you hand your packets to the attacker to

   It MAY substitute labels on the leftmost dot-
   separated part of the NAI with the single character "*" to indicate a
   wildcard match for "all labels in this part".
Use the singular form here to avoid confusion:
  It MAY substitute the leftmost dot-
   separated label of the NAI with the single character "*" to indicate a
   wildcard match for "all labels in this part".

S3.4.1 is the first mention of UTF-8 realms, which are not permitted
by RFC 4282.  This was a point of confusion for me.  I note that the
new nai draft permits UTF-8 realms.  Please just cite that and remove
the reference to 4282.

S 3.4.3 doesn't cover how to handle NAPTR records with flags set to
"a", though other parts of the document describe that.  I think there
is some refactoring of the dependency on the S-NAPTR algorithm, and an
allowance for a default port.

Nits/editorial comments:

S1.3 Capital 'P' on first bullet
S2.1.1.1 Missing period on first note.
S2.1.1.2 Please provide a reference for "Effective TTL".
S2.1.1.3 s/PKS/PSK/ and "used for in the subsequent"
(S2.1.3 Please be consistent with the trailing period in DNS record entries)
2.1.3.c. "x-" ugh...RFC 6648
S.3.4.4 "If these
   TTLs are very low, thrashing of connections becomes possible; the
   Effective TTL mitigates that risk." - isn't this the MIN_EFF_TTL instead?
S3.4.4 the last MAY here can be a SHOULD, I think
S5 "the result O can not be trusted" -> "the result of the discovery
process can not be trusted"