IPS Security draft Last Call Comments

[Black_David@emc.com]

Here are my IPS Security draft last call comments.  Overall, it's a
nicely written draft - kudos to the authors and contributors.

A quick glance at the normative references (and the fact that the main
protocol drafts have to make a normative reference to the security draft)
suggests that the security draft will be the center of an IPS draft
"hairball" (a bunch of drafts that have to be published as RFCs at the
same time, due to normative references) - this doesn't appear to be
easily avoidable, but it looks like all of the drafts involved are
quite close to done, with one exception ...

-- Technical

[1] AES Counter mode is not making good progress in the ipsec WG.  To avoid
having this hold up everything, I propose the following approach:

(1) Take the relevant IP Storage WG drafts through WG Last Call with the
	AES Counter mode SHOULD as it currently stands (i.e., make no
changes
	to this now).
(2) Put an item on the IPS Yokohama agenda (and further mailing list
discussion)
	about whether the fallback position (if we have to take out the
	AES Counter mode reference) should be AES CBC or just deleting AES.
(3) Defer the actual decision on whether to remove the AES Counter reference
	until later this year - the mechanism to make this change would be
	a comment submitted to the IETF Last Call.

Don't panic ... this should not impact the time required to get the IPS
drafts out as RFCs.  In some sense this is a Last Call "Non-comment" as
I'm proposing to defer this issue to IETF Last Call, but work out in
advance how it will be dealt with.

[2] p.13: Section 2.3.3 IKE

I have a concern with the following text:

  The Phase 2 Quick Mode exchanges used by IP block storage protocol
  implementations MUST explicitly carry the Identity Payload fields (IDci
  and IDcr).  Each Phase 2 IDci and IDcr Payload SHOULD carry a single IP
  address (ID_IPV4_ADDR, ID_IPV6_ADDR) and a single non-zero port number,

The "and a single non-zero port number" wording applies a SHOULD
to a finer granularity of SAs than we might like - for a simple situation
of one Initiator, one Target, dynamically allocated Initiator TCP ports and
a single Target contact port, the result is that the Initiator SHOULD use
an SA per connection, whereas the Target MAY use a single SA to span all
connections.  I suggest just deleting the "and a single non-zero port
number" wording to remove this asymmetry as a SHOULD for using a dynamically
allocated port as an identifier doesn't make a lot of sense.  Requiring
IDcr to be a single port in this sort of situation is somewhat more
justifiable, but I don't think it's necessary.

If that change is made, the "MUST" does not appear to be necessary,
as RFC 2409, Section 5.5 says:

   The identities of the SAs negotiated in Quick Mode are implicitly
   assumed to be the IP addresses of the ISAKMP peers, without any
   implied constraints on the protocol or port numbers allowed, unless
   client identifiers are specified in Quick Mode.

I would rephrase the text to say "If the Phase 2 Quick Mode exchanges used
by IP block storage protocols carry the Identity Payload ..." and
possibly add a comment if security policy requires restricting the
identity to a single port, then the corresponding Identity Payload must
be used.

[3] p.21 SLPv2 security implications

I suggest expanding the paragraph starting with:

  This can be accomplished by restricting the issuance of certificates
  valid for use in SLPv2 service advertisement.

This paragraph describes the approaches of using a different CA to
issue certificates valid for SLPv2 and putting explicit SLPv2 authorizations
into the certificates.  Both of these involve certificates that may be
specific to SLPv2.  An approach that avoids this would be to record the
identities allowed in each client that uses SLPv2 - this is primarily
useful when DAs are used, as one would then only need to record the
allowed identities of the DAs and trust the DAs to enforce policies
about who can register what with them.  This approach is of interest
only because it avoids certificate customization for SLPv2.

[4] p.25: Section 2.6.4 iSNS Server Implementation Requirements

The following text appears to have been overlooked in the changes
after Minneapolis:

  The implementation
  MUST conform to [RFC2401] requirements for support of ESP in transport
  mode.  Section 4.1 of [RFC2401] states:

     a) A host MUST support both transport and tunnel mode.
     b) A security gateway is required to support only tunnel
        mode.  If it supports transport mode, that should be used
        only when the security gateway is acting as a host, e.g.,
        for network management.

It should be replace with "MAY support transport mode" or the equivalent.

[5] p.25: Section 2.6.4 iSNS Server Implementation Requirements

  Manual keying SHOULD NOT be used
  since it does not provide the necessary rekeying support.

I think this should be rephrased to talk about consistency with
the IP Storage protocols that iSNS provides information for.  The
issue leading to the SHOULD NOT for manual keying is that IP Storage
protocols can be expected to send data in high volumes, thus using
up sequence number space and the like at a fairly rapid clip.  iSNS
is not going to be sending a lot of data, and if we were considering
only iSNS in isolation, manual keying might be defensible.  Overall,
I think the "SHOULD NOT" is correct, but it needs to be justified
via consistency of policies/mechanisms in an IP Storage infrastructure.

[6] p.31, last paragraph before Section 4:

     Note that if both ends of the connection are on the same segment,
     then traffic will be effectively protected by the layer 2 CRC, so
     that negotiation of the iSCSI CRC is not necessary.

Please add "to protect against NIC and network errors, although it may
be desirable for other reasons (e.g., [1] and [2] above)." to the end of
the sentence.

--Editorial

p.11, second bullet:

    These sizes are
    intended as rough order of magnitude guidance, and should not be
    taken as hard Targets or limits (e.g., smaller code sizes are
    always better).

"Targets" should be lower case "targets".

p.27, top of page:

    An iSCSI session [iSCSI], comprised of one or more TCP connections, is
    identified by the 2-tuple of the Initiator-defined identifier and the
    Target-defined identifier, <ISID, TSID>.  

TSID has been renamed TSIH, just change it, don't ask ... and there are
additional TSID occurrences elsewhere in the draft that need this change.

p.30, 3rd paragraph in Section 3.6:

    IPsec offers protection against an attacker attempting to modify packets
    in transit, as well as unintentional packet modifications caused by
    router malfunctions.

Change "router malfunctions" to "network malfunctions or other errors" for
generality.

p.30, next sentence

    In general, IPsec authentication transforms afford
    stronger integrity protection than both the 16-bit TCP checksum and the
    32-bit application-layer CRC that has been proposed for use with iSCSI.

Change "has been proposed" to "is specified".

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------