Re: [Gen-art] Telechat review of draft-ietf-dime-erp-16.txt

[Glen Zorn <[e-mail]>]

On 01/21/2013 12:05 AM, Elwyn Davies wrote:

...

>
 > Document: draft-ietf-dime-erp-16.txt Reviewer: Elwyn Davies Review
 > Date: 20 Jan 2013 IETF LC End Date: IESG Telechat date: 24 jan 2013
 >
 > Summary: Not ready assuming I have correctly identified that the
 > requirements specified in RFC 5295 below are not met by this usage of
 > the DSRK. Generally the use of the term 'domain' in this draft is
 > rather cavalier, as it fails to explicitly tie it back to the
 > restricted meaning of RFC 5295

This statement (roughly echoed by Russ) truly puzzles me.  Section 2 of 
the draft says

    This document uses terminology defined in Aboba, et al. [RFC3748],
    Salowey, et al. [RFC5295], Cao, et al. [RFC6696], and Eronen, et
    al. [RFC4072].

How is that not explicit?  I've reviewed every usage of the term 
"domain" in the draft & it appears to me that the meaning defined in RFC 
5295 and both duplicated and expanded upon (to include the qualifiers 
"home". "visited", etc.) in RFC 6696 applies to each.  Nevertheless, I 
have added the following paragraphs to Section 2 and Section 3, 
respectively.

    Following RFC 5295, the term "domain" herein refers to a key
    management domain unless otherwise qualified.  Similarly, the terms
    "home domain", and "local domain" have the same meaning here as in
    RFC 6696.

    In general, it is assumed that key management domain names and
    Diameter realm names are identical for any given domain/realm.

> and does not clarify how nodes  find out what domain name they should
 > be using.

Please see below.

>
 > Major issues: s5, para 1: Para 1 states:
 >
 > To achieve this, it must learn the domain name of the ER server. How
 > this information is acquired is outside the scope of this
 > specification, but the authenticator might be configured to
 > advertize this domain name, especially in the case of
 > re-authentication after a handover.
 >
 > It appears that declaring learning the domain name out of scope for
 > this specification is in conflict with RFC 5295, para 4 (top of page
 > 12): Usages that make use of the DSRK must define how the peer learns
 > the domain label to use in a particular derivation.

The Diameter ERP Application doesn't use the DSRK, it merely transports 
it.  The technical term "peer" refers here to an EAP (in this case, ERP) 
entity (see RFC 3748); how the peer discovers the key management domain 
name is a matter for an EAP document, not a Diameter document, and in 
fact Section 3.2 of RFC 6696 states in that "The local domain is 
responsible for announcing that same domain name to the peer via a lower 
layer (for example, through DHCP-based local domain name discovery 
[RFC6440] or through the EAP-Initiate/Re-auth-Start message with the 
local ER server)." Therefore, I think that the simplest way avoid 
creating confusion in the guise of being helpful might be to the 
sentence to read "To achieve this, it must learn the domain name of the 
ER server. How this information is acquired is outside the scope of this 
specification."

> Minor issues: s3: In my Last  call review of this document (version
 > 12) I queried the use of the phrase 'the existence of at most one
 > (logical) ER server entity' in two places in s3. I received an
 > answer from one of the the authors that suggested that the phrase was
 > self-explanatory. At the time I did not push back on this and no
 > change has been made. On re-reading the latest version of the draft
 > and the author's reply, I (still) feel that it would help to
 > explain: (1) Why having more than one ER server in a domain is a
 > mistake -

It's not a mistake, but if there is more than one they all need to be 
synchronized WRT the keys they hold.  Section 3 says that.

> apparently because this will  result in EAP 'failing inappropriately'
 > in some cases which would seem to be a reason to specifically
 > deprecate having more then one, and explaining just what the
 > inappropriate consequences would be. (2) The consequences of having
 > zero ER servers in a domain. The reply to my comments seem to imply
 > that this would just result in the 'protocol failing gracefully'.
 > However, reading RFC 6695, para 2 of s5.1 seems to imply that having
 > zero ER servers in the local (visited) domain may not be fatal if
 > there is an ER server in the home domain (see also s4 of this draft).
 > If I have interpreted this correctly, then there is a distinction
 > between the cases (home vs arbitrary visited domain) that could
 > usefully be brought out here rather than leaving the reader to work
 > it out from later reading.
Once again, this is a matter for an EAP specification, not a Diameter 
protocol doument.  That's also why the assumption is an assumption: we 
have no business telling people how to deploy EAP/ERP in networks.  We 
also assume that anyone implementing the protocol described in the draft 
understand, at a minimum, how EAP, ERP and Diameter work.  Given this 
understanding, it should be immediately obvious why there must be at 
most one ERP and/or EAP server in a given domain.

>
 > s3, last sentence of para 1: ''we assume only one ER server that is
 > *near* the peer involved in ERP": How are we to interpret 'near'
 > here? Topologically or physically? How would the peer know a server
 > was 'near' it or nearer than some other server?

The EAP peer need know nothing about the locations of ER servers. 
Distance here is measured in terms of Diameter hops; this has been 
clarified, I hope, by the following change to the first paragraph of 
Section 3:

    If multiple ER servers are
    deployed across multiple domains, we assume that only one ER server,
    topologically close to the peer, is involved in ERP, distance being
    measured in terms of Diameter hops.

>
 > Nits/editorial comments: s2/s3: I assume that the term 'domain' is
 > intended to be interpreted as in RFC 5295, i.e. as a shorthand for
 > Key Management Domain. This needs to be spelt out here. Similarly
 > 'home domain', 'local domain' and 'visited domain' should be
 > explicitly mentioned as (presumably) having the same meanings as in
 > RFC 6696.

See above.