Subject: [Gen-art] Gen-ART Review (LC) of draft-jeong-dnsop-ipv6-dns-discovery-08.tx t

From: "Gray, Eric" <[email-masked]>
Date: Tue, 27 Jun 2006 12:04:53 -0400

I am the assigned Gen-ART reviewer for:

	draft-jeong-dnsop-ipv6-dns-discovery-08.txt

For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

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

---------------------------------------------------------------------

This document does not appear to be quite ready for publishing as an 
Experimental RFC at this time.  

I have included below several comments and questions that should be 
resolved or clarified.

Comments:
========

In the last sentence of section 1.1, I cannot be certain I am parsing
this correctly as it is now.  Here is what I believe you are saying:

"Using the lifetime field differentiates the RA approach
 from the DHCPv6 approach in that it allows mobile nodes 
 to use local RDNSSes rather than remote RDNSSes in order 
 to reduce the DNS resolution delay [6]-[8]."
----------------------------------------------------------------------

In section 3, you define "Recursive DNS Server (RDNSS)" in terms of
a "recursive DNS resolution service".  I believe this is a well-known
concept in this domain of interest, but it would be helpful if you 
would also define what you mean by this, or point to somewhere where
it is defined.

The term is not defined in your references [4] and [5] (though many
more fundamental terms - such as "IP" - are).
----------------------------------------------------------------------

I am having some difficulty in figuring out what it means to have a
"hysteresis" delta in the values of the "PREF" field of the RDNSS
option - i.e. - why the special values of 8 and 11 (or 8 through 11).

In particular, I am having difficulty in reconciling the fact that -
as this field is now defined - it is possible to have multiple PREF
values that are "equivalent" to (neither greater than or less than)
manually configured RDNSS values, yet are different from each other.

After a few times re-reading this, it appears that you want to have
the values 8-11 reserved for manually configured RDNSS PREF values.
Then, it is possible to choose multiple values for RDNSS PREF in a
RDNSS option that are guaranteed to be higher than, or lower than,
any manually configured RDNSS PREF values.

This is somewhat murky in the current text.  How is this enforced?
What happens if an RDNSS is manually configured with a PREF of 15,
or 1?  Are manually configured RDNSS values restricted to values 
in this range (by - for instance - having a 2-bit field for PREF)?

The document should probably contain a little bit more on why this
is defined this way.  Minimally, it should clearly state intentions
with respect to limiting use of these values as appropriate (i.e. -
liberal use of "normative" declaration "MUST" and "MUST NOT").
----------------------------------------------------------------------

I am not certain I agree with the sense of section 7 as a whole
and - in particular - the second sentence.

The Security Considerations section appears to equate the RA 
option to ND in general and then to go into details of general 
security issues with ND.  It also explicitly claims (twice) 
that there is no new vulnerability.

I believe there is a new exposure associated with this proposal
as it appears to be intended to define a means to "prefer" a
specific RDNSS based on a PREF value and inferred locality.

In addition to the possibility of setting a higher preference
value in a spoofed message, it is also possible to defeat the
"locality" using an RDNSS option with an infinite lifetime.

While I am reasonably certain that current ND security handles
these issues, it seems to me that they should still be listed.
----------------------------------------------------------------------

I don't understand the note in section 8 (IANA Considerations).

It is not the usual case that this section is removed from an
RFC at the time of publishing.  Perhaps this simply needs to
be re-worded?
----------------------------------------------------------------------

NITs:
====

In section 3, I believe the first sentence might be better worded as:

"This document uses terminology defined in [4] and [5]."

----------------------------------------------------------------------

In section 4, the first sentence of the second paragraph would be 
slightly more readable if the references ([4] and [5]) were in
parentheses.

Also, in the fourth (last) paragraph (first sentence), "of RDNSS 
option" should be "of the RDNSS option" ("RDNSS option" is a term 
that has not been defined at this point in the document).

Alternatively, you could define "RDNSS option" in the terminology
section, or put quotes around it in this instance.

----------------------------------------------------------------------

In section 5.1, on page 6, under "Lifetime" - the second sentence
should read something like this:

"The maximum time, in seconds (relative to the time the packet is 
sent), over which this RDNSS MAY be used for name resolution."

----------------------------------------------------------------------

In section 7, second paragraph, near the end of the paragraph - 
"administatively" should be "administratively".

----------------------------------------------------------------------

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Jaehoon Jeong" <[email-masked]>
Date: Tue, 27 Jun 2006 17:53:25 -0500

Hi Eric,

First of all, I appreciate your efforts on the review of our draft.
There are my answers on your comments inline.

> -----Original Message-----
> From: Gray, Eric [mailto:[email-masked]]
> Sent: Tuesday, June 27, 2006 11:05 AM
> To: Jaehoon Paul Jeong; Soohong Daniel Park; Luc Beloeil; Syam Madanapalli
> Cc: [email-masked]; Mark Townsley
> Subject: Gen-ART Review (LC) of
> Please resolve these comments along with any other Last Call comments

Exactly.

I try to clarify the definition of RDNSS as follows:

o  Recursive DNS Server (RDNSS): Server which provides a recursive
   DNS resolution service for translating domain names into IP
   addresses [RFC1034][RFC1034].

  * RFC1034 and RFC1035 will be replaced with reference numbers.

This default setting is similar to DHCPv6 convention.
For instance, manually configured and DHCPv6-derived DNS resolvers could
have a preference in the 8-11 range (0b10xx) so presumably, a preference of
< 8 means  
less preferred than manual or DHCPv6 while > 11 means more preferred.

I would like to suggest the following text with the purpose of this field
and enforcement for default value for manually configured RDNSSes:

     Pref          The preference of an RDNSS.  A 4-bit unsigned
                   integer.  Preference field allows IPv6 hosts
                   to select a primary RDNSS among several RDNSSes
                   available locally.  A decimal value of 15
                   indicates the highest preference.  A value of
                   zero means unspecified.  The default value of
                   preference MUST be from 8 to 11 for manually
                   configured RDNSSes.  A preference less than 8
                   means less preferred than manual configured
                   RDNSS and a preference greater than 11 means
                   more preferred.

Is this text fine with you?

I don't believe that the preference field introduces another security
problem.
The RDNSSes available locally are preferred to reduce the resolution delay.
If the RDNSS with high preference value cannot serve the DNS resolution
service, it is ignored by the IPv6 host.

> "locality" using an RDNSS option with an infinite lifetime.

When RA Router Lifetime expires, the RDNSS with infinite lifetime for RDNSS
is deleted in the case where S flag is set off. Please refer to NOTE in
Section 6.1 (DNS Server List Management).

The RDNSS with S flag on is used as a last resort, that is, regarded as the
lowest in preference regardless of the RDNSS lifetime. 
So, there is no problem if the ND security is provided.

> these issues, it seems to me that they should still be listed.

Okay, how about the following text?

8.  IANA Considerations

   The IANA assigns a new IPv6 Neighbor Discovery Option type for the
   RDNSS option defined in this document.

                 Option Name               Type
                 RDNSS option              (TBD)

For the NITs, I will correct your comments.

Thanks.

Jaehoon