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

From: Thomas Narten <[email-masked]>
Date: Tue, 22 Apr 2003 13:29:37 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Charles Monia <[email-masked]>
Date: Thu, 24 Apr 2003 14:23:07 -0700

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: [email-masked]
voice: (408) 519-3986
fax:   (408) 435-8385

> -----Original Message-----
> From: Thomas Narten [mailto:[email-masked]] 
> Sent: Tuesday, April 22, 2003 10:30 AM
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Subject: AD review of draft-ietf-dhc-isnsoption-05.txt 
> 
> General issues:
>

---

From: Charles Monia <[email-masked]>
Date: Mon, 28 Apr 2003 17:20:44 -0700

Hi Thomas:

The following are changes proposed in response to your review comments
raising non-editorial issues for the iSNS DHCP option.

> vendor-specific things. Can we just remove them from this

The vendor-specific fields will be redefined as "reserved" fields.

<Material deleted>

> policy configuration" helps mitigate the threats?

We propose the following replacement text.

Section 3.0 -- Security

"[RFC3118] should be consulted to determine the requirements for additional
security measures to verify the authenticity of the iSNS option message
received by the DHCP client.  If necessary, the authentication option
described in [RFC3118] should be utilized.  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 a
hostile entity modifying or replacing the original iSNS option message
should be considered a potential security exposure.  If the authentication
option in [RFC3118] is not implemented, then an attacker may trick the iSNS
client into connecting into rogue iSNS servers.  If the authentication
option for DHCP is not implemented and it is determined that the potential
exists for a "man-in-the-middle" attack, then the DHCP option message for
iSNS SHOULD NOT be utilized.

iSNS security considerations are discussed in [iSNS] and [SEC-IPS]."

-- Charles