RE: iSNS DHC option comments -- response

[Charles Monia <cmonia@NishanSystems.com>]

Hi David:

Please see responses embedded below.

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Wednesday, November 27, 2002 2:15 PM
> To: ips@ece.cmu.edu
> Subject: iSNS DHC option comments
> 
> (1)  If FCIP were to be added, we could run out of space in
> the DD Access field.  I suggest moving the high order octet
> of Administrative Flags to DD Access and making all of
> those new DD Access bits RESERVED for future extensibility.
> 

Response

Accepted.

To provide improved flexibility for other future protocols, we propose to
split the reserved area such that both DD Access and Administrative FLAGS
have reserved fields, with DD Access having more than previously assigned.

Current format is:
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Code = TBD  |    Length     |          iSNS Functions       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   DD Access   |             Administrative FLAGS              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 iSNS Server Security Bitmap                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      a1       |       a2      |       a3      |       a4      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      b1       |       b2      |       b3      |       b4      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            . . . .                            |
    |                 Additional Secondary iSNS Servers             |
    |                            . . . .                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Figure 1 -- iSNS Server Option

The proposed format is shown below.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Code = TBD  |    Length     |          iSNS Functions       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           DD Access           |     Administrative FLAGS      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 iSNS Server Security Bitmap                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      a1       |       a2      |       a3      |       a4      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      b1       |       b2      |       b3      |       b4      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            . . . .                            |
    |                 Additional Secondary iSNS Servers             |
    |                            . . . .                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       Figure 1 -- iSNS Server Option

Section 2.2
      0   1   2   3   4   5   6  ... 15
    +---+---+---+---+---+---+---+---+---+
    | if| tf| is| ts| C | E | Reserved  |
    +---+---+---+---+---+---+---+---+---+
       Figure 3 -- Discovery Domain Access

      Bit field     Significance
      ---------     ------------
         0          iFCP Initiator Port
         1          iFCP Target Port
         2          iSCSI Initiator
         3          iSCSI Target
         4          Control Node
         5          Enabled
       6-15         RESERVED

Section 2.3
    1                           2                   3
    6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                RESERVED                   |D|M|H|E|
   +---+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Figure 4 -- Administrative Flags

               Bit Field               Significance
               ---------               ------------
               31                      Enabled
               30                      Heartbeat
               29                      Management SCNs
               28                      Default Discovery Domain
               27 - 16                 RESERVED




> (2) The Security Considerations need to include the exposure
> to a "bid down" attack on security policy distribution (malicious
> intermediary weakens the security used) and say that reliance on
> local policy to avoid unacceptably weak security is the
> countermeasure.
> 

Response

Comment accepted -- although a standard "bid down" attack will not work
since
the iSNS server will enforce it's own locally-configured security policy.
Rather, the "bid down" attack should be part of a man-in-the-middle attack
to trick the iSNS/DHCP client into connecting to a rogue iSNS server. See
below:

The following text should be added to section 3 Security Considerations:

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].

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.


> Plus a few nits:
> 
> (3) Section 2.3 - Typo in name of bit 28, Discovrery --> Discovery
> 

Accepted.

> (4) The description of the heartbeat should probably talk about
> the Multicast address to which the heartbeat is sent, as opposed
> to the current language about where it originates.
> 

Accepted.

The section will be reworded as follows:

Heartbeat:         Indicates whether the first IP address
                   is the multicast address to which the
                   iSNS heartbeat message is sent.  
                   If set to one, then a1-a4 contains the
                   heartbeat multicast address and b1-b4
                   contains the IP address of the primary
                   iSNS server, followed by the IP
                   address(es) of any backup servers.  If
                   set to zero, then a1-a4 contains the IP
                   address of the primary iSNS server,
                   followed by the IP address(es) of any
                   backup servers.

> (5) Please double check that the PFS bit for security is needed.
> It looks like it is, as I didn't find anything obvious in a quick
> scan of RFC 2409 and the DOI (and IANA registry) only has KEY_IKE,
> and the authentication methods, with nothing to indicate PFS usage.
> 

Response

The PFS bit is needed as a configuration option in the security bitmap.  The
DOI does not include PFS usage.

-- Charles
-----------------------------------------
Charles Monia
Senior Technology Consultant
Nishan Systems
email: cmonia@nishansystems.com
voice: (408) 519-3986
fax:   (408) 435-8385