Re: [Dime] Gen-ART review of draft-ietf-dime-rfc4005bis-11

"Black, David" <david.black@emc.com> Mon, 08 October 2012 20:53 UTC

Return-Path: <david.black@emc.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 EBEA011E80F1; Mon, 8 Oct 2012 13:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 cPELdoa54pNm; Mon, 8 Oct 2012 13:53:16 -0700 (PDT)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id AF71A11E80F0; Mon, 8 Oct 2012 13:53:16 -0700 (PDT)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q98KrEHS006683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Oct 2012 16:53:14 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 8 Oct 2012 16:52:59 -0400
Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q98KqwFY017595; Mon, 8 Oct 2012 16:52:58 -0400
Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Mon, 8 Oct 2012 16:52:58 -0400
From: "Black, David" <david.black@emc.com>
To: Glen Zorn <glenzorn@gmail.com>
Date: Mon, 8 Oct 2012 16:52:56 -0400
Thread-Topic: Gen-ART review of draft-ietf-dime-rfc4005bis-11
Thread-Index: Ac2kXoeQSUAX8En/RPGw5bTX7IkshwBMzE7Q
Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120DF11C25@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE7120DCD17FD@MX15A.corp.emc.com> <50712F0A.1050309@gmail.com>
In-Reply-To: <50712F0A.1050309@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
X-Mailman-Approved-At: Mon, 08 Oct 2012 22:33:57 -0700
Cc: "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-dime-rfc4005bis@tools.ietf.org" <draft-ietf-dime-rfc4005bis@tools.ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "dime@ietf.org" <dime@ietf.org>, "Black, David" <david.black@emc.com>, "dime-chairs@tools.ietf.org" <dime-chairs@tools.ietf.org>
Subject: Re: [Dime] Gen-ART review of draft-ietf-dime-rfc4005bis-11
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: Mon, 08 Oct 2012 20:53:18 -0000

Glen,

Picking up the topics that weren't in Barry's email ...

>  > 1) String preparation so that tests for equality work as expected.
>  > This may suffice for the Called-Station-ID AVP (4.2.5) and
>  > Calling-Station-ID AVP (4.2.6) if the internal structure of those
>  > strings is not used in authorization.
> 
> Both those AVPs are specified to contain ASCII encoded as UTF-8.  Is
> string preparation necessary in that case?

Not in the full glory that is needed for serious usage of UTF-8, but
it looks like the language in the draft should be tightened.  At a
minimum, a "MUST" is in order to require use of 7-bit ASCII encoded
as UTF-8.  Among the reasons for such a requirement is to prohibit the
various ISO/IEC 8859-* character sets (a/k/a Latin-*), which are
8-bit ASCII and not distinguishable from each other on the wire
without an additional character set tag of some form.

I would also suggest forbidding control characters (e.g., require
displayable 7-bit ASCII characters) and saying something about case
handling, starting with whether the strings are case sensitive or case
insensitive.  Case sensitivity is simpler to specify, but may not yield
intuitive and/or expected results.  If the strings are case insensitive,
text should be added to say whether the strings are case-normalized on
the wire and/or whether the recipient is expected to implement case-
insensitive string comparison.

> > 2) Detailed string format for a
>  > string that is processed by a protocol participant, e.g., the
>  > Callback-ID AVP (4.4.3).
> 
> That format is unknown in this case.

Please explain how that's supposed to result in interoperable processing
by the "protocol participant".

>  > [1] End of Section 2 on p.8:
>  >
>  > As a result, service cannot be started as a result of a response to
>  > an authorization-only request without introducing a significant
>  > security vulnerability.
>  >
>  > Please explain what to do about this - a simple rewrite with a
>  > "SHOULD NOT" would suffice, e.g.:
>  >
>  > As a result, service SHOULD NOT be started as a result of a response
>  > to an authorization-only request because that may introduce a
>  > significant security vulnerability.
> 
> The text in question is descriptive, not prescriptive. That said, however,
> I think that it's not really clear.  I think that it should say
> something like "As a result, a new session cannot be started as a result
> of a response to an authorization-only request without introducing a
> significant security vulnerability."
> 
> >
>  > This should also be noted in the Security Considerations section.

The rewrite helps, and make sure to add text about this in the Security
Considerations section.

>  > == Missing Reference: 'BASE' is mentioned on line 219, but not
>  > defined
>  >
>  > That's definitely a problem. Was [I-D.ietf-dime-rfc3588bis]
>  > intended?
> 
> No.  The passage in question is a verbatim quote from RFC 4005.

Ok, just fix this so idnits can find something else to complain about :-).

Thanks,
--David

> -----Original Message-----
> From: Glen Zorn [mailto:glenzorn@gmail.com]
> Sent: Sunday, October 07, 2012 3:28 AM
> To: Black, David
> Cc: glenzorn@gmail.com; lionel.morand@orange.com; gen-art@ietf.org; dime-
> chairs@tools.ietf.org; draft-ietf-dime-rfc4005bis@tools.ietf.org;
> ietf@ietf.org; dime@ietf.org; Benoit Claise
> Subject: Re: Gen-ART review of draft-ietf-dime-rfc4005bis-11
> 
> On 09/18/2012 06:53 AM, Black, David wrote:
> 
> > 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-rfc4005bis-11 Reviewer: David L. Black
>  > Review Date: September 17, 2012 IETF LC End Date: September 18, 2012
>  > IESG Telechat date: (if known)
>  >
>  > Summary:
>  >
>  > This draft is on the right track but has open issues, described in
>  > the review.
>  >
>  > This draft is part of a set of drafts that updates the DIAMETER
>  > protocol; this draft specifies the application of DIAMETER to AAA for
>  > network access. The draft is heavily based on RFC 4005, which it
>  > obsoletes, and requires significant DIAMETER familiarity (including
>  > familiarity with its companion drafts, starting with the rfc3588bis
>  > draft) for complete understanding.
>  >
>  > The draft is in good shape and reads well. I found one major open
>  > issue, a few minor issues, and several nits.
>  >
>  > Major issues:
>  >
>  > This draft makes significant use of UTF-8 in its formats (some
>  > subsections of sections 4.2, 4.4 and 4.5) for strings that are
>  > intended to be compared for equality or processed by protocol
>  > participants, but does not contain considerations for Unicode
>  > processing that are sufficient to support this usage. Examples of
>  > UTF-8 usage in this draft include:
>  >
>  > - 4.2.5 and 4.2.6: The NAS server may perform authorization based on
>  > the Called-Station-Id and Calling-Station-Id AVPs under some
>  > circumstances. - 4.4.3: The Callback-Id AVP is intended to be
>  > interpreted by the NAS.
>  >
>  > All use of UTF-8 in this draft relies upon the specification of the
>  > UTF8String format in the rfc3588bis draft. That specification is
>  > insufficient to support the usage in the above examples, and there
>  > are no Unicode considerations in this draft. Even binary comparison
>  > of Unicode strings for equality generally requires specification of
>  > string preparation (e.g., normalization) in order for string
>  > comparison to work as expected.
>  >
>  > The variety of Unicode strings in this draft makes it important to
>  > lay out the Unicode requirements and considerations for each AVP. I
>  > see at least 5 classes of possible Unicode
>  > requirements/considerations:
>  >
>  > 1) String preparation so that tests for equality work as expected.
>  > This may suffice for the Called-Station-ID AVP (4.2.5) and
>  > Calling-Station-ID AVP (4.2.6) if the internal structure of those
>  > strings is not used in authorization.
> 
> Both those AVPs are specified to contain ASCII encoded as UTF-8.  Is
> string preparation necessary in that case?
> 
> > 2) Detailed string format for a
>  > string that is processed by a protocol participant, e.g., the
>  > Callback-ID AVP (4.4.3).
> 
> That format is unknown in this case.
> ...
> > 5) Statement that the string  contains an FQDN, as stated for one case of
>  > the Tunnel-Client-Endpoint AVP in 4.5.4. That specific statement is
>  > incomplete, as it needs to be accompanied by a normative reference to
>  > a document that specifies the format of internationalized domain
>  > names, and probably needs to also state which types of labels (e.g.,
>  > A-label, U-label) are allowed.
>  >
>  > Every use of UTF8String in this draft needs to be checked, and most
>  > of them are likely to need some attention. The ongoing work in the
>  > precis WG may help with some of this, and I would suggest talking to
>  > the APP ADs, especially Pete Resnick (hi Pete) before embarking on
>  > significant work in this area in order to avoid wasted or duplicated
>  > efforts.
> 
> OK, this last one bothers me a lot: you /seem /to be suggesting that we
> hold up this draft to wait for the result of a WG which has yet to
> publish a problem statement.  I'm sure that that is not the case, but it
> sure sounds like it.
> 
> >
>  > Minor Issues:
>  >
>  > [1] End of Section 2 on p.8:
>  >
>  > As a result, service cannot be started as a result of a response to
>  > an authorization-only request without introducing a significant
>  > security vulnerability.
>  >
>  > Please explain what to do about this - a simple rewrite with a
>  > "SHOULD NOT" would suffice, e.g.:
>  >
>  > As a result, service SHOULD NOT be started as a result of a response
>  > to an authorization-only request because that may introduce a
>  > significant security vulnerability.
> 
> The text in question is descriptive, not prescriptive.at said, however,
> I think that it's not really clear.  I think that it should say
> something like "As a result, a new session cannot be started as a result
> of a response to an authorization-only request without introducing a
> significant security vulnerability."
> 
> >
>  > This should also be noted in the Security Considerations section.
>  >
>  > [2] In the message formats in Section 3, QoS-Filter-Rule is
>  > inconsistently capitalized.
> 
> OK, thanks.
> 
> > Also the use of QoSFilterRule  as the
>  > format for the QoS-Filter-Rule AVP in Section 4.1.1 is potentially
>  > confusing. Please add a sentence in 4.1.1 to say that QoSFilterRule
>  > is the format for the QoS-Filter-Rule AVP.
>  >
>  > [3] Section 4.2.1. In this and the other AVP Flag Rules tables,
>  > please explain what the values in the MUST and MUST NOT columns
>  > mean.
>  >
>  > [4] Based on this text in 4.4.9:
>  >
>  > The use of this AVP is NOT RECOMMENDED; the AVPs defined by
>  > Korhonen, et al. [RFC5777] SHOULD be used instead.
>  >
>  > I would have expected RFC5777 to be a Normative Reference, not an
>  > Informative Reference.
> 
> I don't care particularly, but I don't think that it's really necessary
> to understand RFC 5777 to understand this document.
> 
> >
>  > Nits/editorial comments:
>  >
>  > After the command table in Section 3 and other similar tables, please
>  > add a sentence to say that the -Request and -Answer commands in each
>  > similarly-named command pair are distinguished by the value of the
>  > 'R' bit in the Command Flags field of the command. This is already
>  > stated in the command definitions, but the sentence should be added
>  > after the table for clarity because each command pair shares a
>  > Command Code.
>  >
>  > idnits 2.12.13 found a few potential nits:
>  >
>  > == There are 7 instances of lines with non-RFC5735-compliant IPv4
>  > addresses in the document. If these are example addresses, they
>  > should be changed.
>  >
>  > That can probably be ignored, as these instances are likely generated
>  > by text such as cross-references to Section 4.4.10.1
>  >
>  > == Missing Reference: 'BASE' is mentioned on line 219, but not
>  > defined
>  >
>  > That's definitely a problem. Was [I-D.ietf-dime-rfc3588bis]
>  > intended?
> 
> No.  The passage in question is a verbatim quote from RFC 4005.
> 
> >
>  > -- Possible downref: Non-RFC (?) normative reference: ref.
>  > 'ANITypes'
>  >
>  > That reference would be:
>  >
>  > [ANITypes] NANPA Number Resource Info, "ANI Assignments",
>  > <http://www.nanpa.com/ number_resource_info/
>  > ani_ii_assignments.html>.
>  >
>  > Is that reference sufficiently stable (e.g., IANA-class or better
>  > management)?
> 
> Yes, I think so.
> 
> > My guess is that it is  sufficiently stable, but I'm not
>  > the expert.
> >
>  > -- Obsolete informational reference (is this intentional?): RFC 1334
>  > (Obsoleted by RFC 1994)
>  >
>  > That reference may be intentional,
> 
> Yes.
> 
> ...