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

[Thomas Narten <[e-mail]>]

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