Subject: Comments on draft-ietf-ipfc-fibre-channel-04.txt

From: Lansing Sloan <[email-masked]>
Date: Thu, 18 Feb 1999 15:00:37 -0800

Hi,

   I have a few comments on draft-ietf-ipfc-fibre-channel-04.txt.

   On the whole, I'd like to see this document progress.

8. SECURITY CONSIDERATIONS

   Most of the remarks in the draft seem directed toward integrity
in the absence of deliberate attacks.  I would think that if an
attacker can modify bits successfully, the attacker could also
provide a replacement CRC, for example.

   If a simple security-considerations section is desired,
I think the InARP document, RFC2390, illustrates the type and
level of discussion that might be warranted.

   From a technical point of view I think it is hard to summarize Fibre
Channel vulnerabilities.  Speaking very roughly, Fibre Channel
(FC-2 level) has various options, some of which
correspond to TCP in attackability, others of which
correspond to IP or Ethernet in attackability.

   If the IESG considers the current text to be acceptable, however,
that's fine with me.

F.1 RELIABILITY IN CLASS 3

   As the first paragraph states, it is possible for Fibre Channel
Class 3 to reassemble a fragmented information unit incorrectly.
If higher-level protection methods (such as the TCP checksum) are
not used or fail to detect the incorrect reassembly, corrupted data
gets delivered.

   Speaking very roughly, this problem is analogous to the problem
that ATM AAL-5 would have if AAL-5 did not employ a CRC after
reassembly.  Given the work that Craig Partridge and Jim Hughes
did, which disclosed that the TCP checksum would be remarkably ineffective
for detecting ATM AAL-5 reassembly errors in some kinds of data, I have some
concern about Class 3 reassembly being used in parts of the Internet.

   If the data integrity concerns were alleviated, I think Class 3
(unacknowledged-delivery service) would be quite appropriate in many
cases.

   My intuition is that of the three mechanisms suggested in F.1:
   * the second (start a new Exchange) is dangerous for the reasons
     described in the note;
   * the first (continuously increasing sequence count) might be
     dangerous when Exchanges have a very short lifetime, because
     each new Exchange must start with the same SEQ_CNT value of 0,
     leading to the same potential vulnerability as the second
     mechanism.  If there were a way to ensure Exchanges had a long
     enough lifetime, this approach might be acceptable;
   * the third (only single-frame Sequences) seems perfectly safe.

   The IESG may feel that such integrity risks are acceptable in the
Internet, since many systems on the Internet have other
problems.  If the IESG feels this way, that is fine with me.

IS "OPTIONAL HEADER" PART OF FC PAYLOAD?

   Is the "Optional Header" of figure 1 part of the "Payload", or not?
   Note that the "Optional Header" is the non-optional "Network" header
in this document.
   Figure 1 certainly implies the optional header is not part of the
payload.
   Section 3.2.1, third paragraph, third sentence, says it is part of
the payload.
   Section 3.4 seems to imply it is not part of the payload, since it
is not shown in the figures nor discussed in the text for IP and ARP.
   In section 7.4, the value "92" in note 3b and the value "52" in note
3c are correct if the optional header is part of the "payload"; but if
the header is not part of the payload these values should each be reduced
by 16 to "76" and "36", respectively.

   I believe the document should try to be consistent about whether
the optional header is or is not part of the FC payload; and should
be consistent with other Fibre Channel standards documents.  (From my
reading of the ANSI X3.230-1994 section 3.1, I'd say the optional header
is not part of the payload, hence figure 1 is correct and sections 3.2.1
and 7.4 should be changed.)

3.1 FC FRAME FORMAT

   Figure 1 shows the size of variable fields ranging from "0-2112B"
but the immediately preceding text states "0 to 2111".  One of these
should be corrected.

   The above opinions are strictly my own, and not necessarily those
of my employer.

-- Lansing Sloan