Subject: [dhcwg] AD review of draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt

From: Thomas Narten <[email-masked]>
Date: Wed, 14 May 2003 15:48:17 -0400

No big issues with this document, I went ahead and requested an IETF
LC. Here are my review comments.

NIS in abstract will likely need to be spelled out to satisfy rfc
editor..

>    This document uses terminology specific to IPv6 and DHCPv6 as defined
>    in section "Terminology" of the DHCP specification.

would be good to cite the RFC...

>    The format of the Network Information Service Servers option is as
>    as shown below:

s/as as/as/

>    The Network Information Service Servers option provides a list of 
>    one or more IP addresses of NIS servers available to the client. The
>    NIS servers SHOULD be listed in the order of preference.

I think I understand the intent, but I think it would be more clear to
write this something like:

Clients MUST treat the list of servers as an ordered list.  Servers
(when they care) need to fill the fields in priority order (they are
not required to).

The above words don't really say the client MUST treat the option as
an ordered list.

Same wording issue appears in other places.

> 8. Appearance of these option

s/option/Options/ (also capitalize heading for consistency?)

> 9. Security Considerations
> 
>    The NIS servers, NIS+ servers, NIS domain name and NIS+ domain name 
>    options may be used by an intruder DHCP server to assign invalid NIS 
>    parameters, resulting in clients unable to use NIS.

Is this really correct? it makes it sound like there is only a DOS
issue. Can't this option be used to send someoneto use a spoofed
server, in which case the server can provide bad responses that cause
errors or security compromises, or?

> 10. IANA Considerations
> 
>    IANA is requested to assign an option code to these options from the
>    option-code space defined in section "DHCPv6 Options" of the DHCPv6
>    specification [1].

Would be good to list the options in this section together with TBDs
and pointers to the  sections. The way things are written now, IANA
has to scan the document in more detail to figure out what it needs to
do.

> 12. Informative References
> 
>    [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
>         Levels", BCP 14, RFC 2119, March 1997.

This references is generally considered normative.

Thomas
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Vijayabhaskar A K" <[email-masked]>
Date: Thu, 15 May 2003 02:21:47 +0530

Thomas,

I agree with all your comments and I will update it, But I am not sure
of the case you have suggested in "Security Considerations", I couldn't
imagine a scenario of security vulnerability, anyhow, I will update it
with "May be" clause.
Thanks for your comments

Vijay

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Thomas Narten
> Sent: Thursday, May 15, 2003 1:18 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [dhcwg] AD review of 
> draft-ietf-dhc-dhcpv6-opt-nisconfig-02.txt
> 
> 
> No big issues with this document, I went ahead and requested 
> an IETF LC. Here are my review comments.
> 
> NIS in abstract will likely need to be spelled out to satisfy 
> rfc editor..
> 
> I think I understand the intent, but I think it would be more 
> clear to write this something like:
> 
> Clients MUST treat the list of servers as an ordered list.  
> Servers (when they care) need to fill the fields in priority 
> order (they are not required to).
> 
> The above words don't really say the client MUST treat the 
> option as an ordered list.
> 
> Is this really correct? it makes it sound like there is only 
> a DOS issue. Can't this option be used to send someoneto use 
> a spoofed server, in which case the server can provide bad 
> responses that cause errors or security compromises, or?
> 
> > 10. IANA Considerations
> > 
> Would be good to list the options in this section together 
> with TBDs and pointers to the  sections. The way things are 
> written now, IANA has to scan the document in more detail to 
> figure out what it needs to do.
>

---

From: Thomas Narten <[email-masked]>
Date: Thu, 15 May 2003 11:22:48 -0400

Hi Vijay.

> imagine a scenario of security vulnerability, anyhow, I will update it

I actually don't know if there is vulnerability. But I would expect
there might be. So I'm asking for someone more knowledgable than I
about NIS to asssure me that there is no vulnerabilty. As I was

>    parameters, resulting in clients unable to use NIS.

hard to believe on the surface. Is the only damage that can occur a
DOS attack? I would have assume that NIS provides a service, that if
spoofed, can cause the wrong thing to happen (as in incorrect
results), not just DOS (which is what I inerpret "unable to use NIS"
to mean).

Thomas