[dhcwg] RE: AD review of draft-ietf-dhc-isnsoption-05.txt

[Charles Monia <[e-mail]>]

Hi Thomas:

Thanks for your input.

I will be making the changes to fix the editorial problems you've pointed
out along with adding the section on IANA considerations.  I have asked for
input from the other co-authors on the technical issues, including vendor
specific fields and security and will post responses to those issues when
available.

-- Charles
-----------------------------------------
Charles Monia
Senior Technology Consultant
Nishan Systems
email: [e-mail]
voice: [phone]
fax:   [phone]
 

> -----Original Message-----
> From: Thomas Narten [mailto:[e-mail]] 
> Sent: Tuesday, April 22, 2003 10:30 AM
> To: [e-mail]; [e-mail]; 
> [e-mail]
> Cc: [e-mail]
> Subject: AD review of draft-ietf-dhc-isnsoption-05.txt 
> 
> General issues:
> 
> I'd like to see a justification for the vendor specific fields. I'd
> like to understand how these can be safely used without leading to
> interoperability issues. Besides, there are other ways in DHC to do
> vendor-specific things. Can we just remove them from this
> option/document?
> 
> The security considerations section is rather weak.
> 
> General note: this document is inconsitent about bit ordering. Some
> picture show bits numbered left-to-right, others right-to-left. Please
> pick one and be consistent.
> 
> needs an IANA considerations section. 
> 
> I assume a revision of the document would be in order before starting
> the IETF LC.
> 
> Specific comments follow.
> 
> >                    DHCP Options for Internet Storage Name Service
> 
> Would be good for the title to note that this is for DHCP for
> IPv4. E.g.:
> 
>               The IPv4 DHCP Option for Internet Storage Name Service
> 
> Abstract doesn't satisfy ID nits; e.g., has unexpanded acronyms.
> 
> "iSNS" used before being defined.
> 
> ditto for iSCSI, iFCP, etc.
> 
>         The Dynamic Host Configuration Protocol for Ipv4 provides a
> 
> s/Ipv4/IPv4/
> 
> >         Existing DHCP option numbers are not plausible due 
> to the following
> >         reasons:
> 
> suggested reword:
> 
>          Existing DHCP options cannot be used to find iSNS servers for
>          the following reasons:
> 
> >         Length: the number of bytes that follow the Length 
> field.  The
> >                 minimum value for the Length field is 6 in 
> order to account
> >                 for the iSNS Functions, Discovery Domain Access, and
> >                 Administrative Flags fields.
> 
> From the picture, it seems like the minimum length is more than
> 6. Are some of the fields optional?
> 
> >         certificates for the use of iSCSI and iFCP devices. 
> The format of
> >         the iSNS Role bit field is shown in Figure 2:
> > 
> >                        1       2                   3
> >                        6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >                      +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >                      |Vendor-Specific |RESERVED |S|A|E|
> >                      +--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >                      Figure 2 -- iSNS Functions
> 
> I don't see how a vendor-specific portion of this option facilitates
> interoperability. Remove?
> 
> Also, caling it the "iSNS Role" field is confusing, since that is not
> used in the previous figure. SHouldn't this be the "iSNS Functions"
> field?
> 
> 
> >                 Bit field     Significance
> >                 ---------     ------------
> >                 31            Function Fields Enabled
> >                 30            DD-Based Authorization
> >                 29            Security policy distribution
> >                 28 - 24       Reserved
> >                 23 - 16       Vendor-specific
> 
> You need a transistion sentence saying what field is being talked
> about. Presumably, this is "iSNS Server Security Bitmap"?
> 
> >                 Enabled:        This bit specifies the 
> validity of the
> 
> Spell out "Function Fields Enabled", as that is the name of the field
> per the picture.
> 
> >                 Security:       Indicates whether the iSNS 
> client is to
> 
> spell out field name.
> 
> >                 Vendor-         These bits are used to 
> indicate the vendor-
> >                 Specific:       specific capabilities 
> supported by the
> >                                  indicated iSNS server.
> 
> Again, this does not promote interoperability. There are other ways in
> DHC to communicate vendor specific information.
> 
> General note: this document is inconsitent about bit ordering. Some
> picture show bits numbered left-to-right, others right-to-left. Please
> pick one and be consistent.
> 
> >      3.       Security Considerations
> > 
> >         DHCP currently provides no authentication or 
> security mechanisms.
> >         Potential exposures to attack are discussed in 
> section 7 of the DHCP
> >         protocol specification [DHCP].
> 
> What about RFC 3118?
> 
> 
> >         iSNS security considerations are discussed in 
> [iSNS] and [SEC-IPS].
> >         With regard to security considerations specific to 
> the use of this
> >         DHCP option to discover the location of the iSNS 
> server, exposure to
> >         a "man-in-the-middle" attack by an hostile entity 
> modifying or
> >         replacing the original iSNS option message should 
> be considered a
> >         potential security exposure.  To prevent an 
> attacker from weakening
> >         the required security and potentially tricking the 
> iSNS client into
> >         connecting into rogue iSNS servers, reliance on 
> local security
> >         policy configuration is an appropriate countermeasure.
> 
> This says almost nothing. What can happen if there is a  man-in-the
> middle? Really bad things? or just DOS? And what "local security
> policy configuration" helps mitigate the threats?
> 
> Thomas
> 
_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg