Company-# Technical Physical Section/table/figu Problem Description
/Editorial Page (not re locator
pdf page)
McDATA-1 E I Points of Contact Jim is no longer with Brocade.
McDATA-2 E iii Abstract This is a run-on sentence.
McDATA-3 E v Foreword The first paragraph is redundant.
Foreword,
second "The standards approval process started in
McDATA-4 E v paragraph 2003." is unnecessary.
McDATA-5 E viii Introduction We're not in Rome, get rid of the Latin.
McDATA-6 E xiv blank page delete all blank pages.
McDATA-7 E 1 scope You're repeating yourself.
Need to include the reference where the DH
Group Id's used for authentication originated
from.
McDATA-8 E 3 2.4
B_Ports and
McDATA-9 E 5 E_Ports These should reference SW-4
There are too many reference definitions. Is
McDATA-10 E 5 FS references this the way we want to define the terms?
Add definition for Perfect Forward Secrecy for
McDATA-11 E 5 Definitions completeness.
Change DH-CHAP to DHCHAP as used in the
McDATA-12 E 7 General rest of the document.
Remove reference to IETF IKEv2 draft or
McDATA-13 E 7 IKEv2 replace with reference to an RFC.
McDATA-14 E 9 first sentence makes s/b makes it
Silly wording: the "importance" or
"unimportance" of FC fabrics has no
relationship to the adequacy of relying on their
McDATA-15 E 9 first sentence physical security.
McDATA-16 E 9 second sentence span across s/b span
McDATA-17 E 9 third sentence Delete word "then"
Here (and in the next para), "secret key" is
used, while in Figure 1, "Shared Key" is used.
4.3 second
McDATA-18 E 9 paragraph ???
4.1 third
McDATA-19 E 9 paragraph Change "risk" to "risks"
Add (i.e. Message Authentication) after
McDATA-20 E 9 4.2 Integrity.
Seems like "secret-based" and "password
based" amount to the same thing. What is the
difference, other than there are three
4.3 first authentication protocols defined?
McDATA-21 E 9 paragraph
4.3 first Reword to "Three authentication protocols are
paragraph, lst defined but only one is required for
McDATA-22 E 9 sentence interoperability."
Change FCAP to FCCAP throughout to more
accurately desribe this protocol.
(Fibre Channel Certificate Authentication
McDATA-23 E 9 last paragraph Protocol).
Define "digitally sign" or "digital signature" in
definitions section for completeness and add
McDATA-24 E 9 last paragraph reference.
What is a Security Association and how is it
McDATA-25 T 9 4.3 used?
There is no mention of using IKEv2 as a
standalone protocol for authentication,
McDATA-26 T 10 first paragraph although it is a fourth option shown in 4.4.
McDATA-27 T 10 Figure 1 Can they negotiate to not authenticate?
McDATA-28 E 10 Figure 1 This graphic could be improved in many ways.
McDATA-29 E 10 a, b, c Add word "Required" to the DHCHAP line.
The first paragraph below Figure 1 are a repeat
McDATA-30 E 10 a, b, c of the previous page.
There's no clear definition of SA here. In IP
world, IKE establishes SA dynamically but SA
can also be defined by security policy statically.
It's not clear whether it's true in FC since
McDATA-31 T 11 4.5 there's no definition of security policy.
Change from "what are..."
McDATA-32 E 11 second sentence to "what the characteristics... are."
McDATA-33 E 11 line above a) Change "by" to "of"
McDATA-34 E 11 fourth sentence ESP_Header s/b The ESP_Header
paragraph below You must be looking for trouble. Too many
McDATA-35 E 11 a-b list whiches.
McDATA-36 E 11 last sentence Add word "provides". Delete "also".
composed by s/b composed of. These
Fabric policies sentences can be combined into one
McDATA-37 E 11 paragraphs paragraph.
Is the intent to allow for additional switch types
in the future or to just modify the definitions of
these switch types? A rigid definition for "types
of switches" makes it difficult to modify or
extend in the future. For example, one
proposal was shown that would allow other
information to be potentially gathered by Client
switches in the future. How would that be
McDATA-38 T 12 4.6.2 handled in a FC SP 2?
McDATA-39 E 12 General Where is this section covered in details?
McDATA-40 T 12 Figure 2 Doesn't show CT Authentication model.
McDATA-41 E 12 Figure 2 SPD is not defined yet.
SPD details needed. What are the required
interoperable behaviors of an SPD? Where is
the interface to the SPD defined in this
McDATA-42 T 12 Figure 2 standard?
Reauthentication can happen at any time - not
McDATA-43 T 12 4.6.3 just when a connection is attempted.
McDATA-44 E 13 third paragraph selector s/b Traffic Selector
McDATA-45 E 13 third paragraph are s/b is
last sentence of This should also be explained better in a new
McDATA-47 T 13 first paragraph section describing Security Associations.
5.1 fourth Authentication transaction s/b "Authentication
McDATA-48 E 15 paragraph Transaction" throughout this doc.
This first sentence seems to conflict with other
clauses of the document. For example, 5.9.5
first sentence that says an Nx_Port is always the sender of
McDATA-49 T 15 below Figure 3 AUTH_Negotiate.
What does it mean to "close communication"?
close These states and standards should be
McDATA-50 T 16 communication consistent across multiple standards.
first sentence of
paragraph before
McDATA-51 E 16 5.2 "of" s/b "to"
Fibre Channel Authentication protocols s/b
authentication protocols or Authentication
McDATA-52 E 16 5.2.1 Protocol, consistently in the document.
McDATA-53 E 17 Flags: Flags s/b AUTH_ILS Flags
McDATA-54 E 18 Flags: Flags s/b B_AUTH_ILS Flags
Add note indicating what the proper behavior of
Protocol Version fields of other values should
be.
Note: A version of 00 is rejected. The purpose
of the version field is to change for major
revisions of the protocol when downward
compatibility may not be possible. For
implementations supporting version 1 only, a
McDATA-55 E 19 Protocol Version version greater than 01 is rejected.
Transaction Identifier (page 19)
Suggest that the standard makes the rules for
incrementing the transaction Identifier common
Transaction for all Authentication Protocols.
McDATA-56 E 19 Identifier
The "command dependent portion" clause is
McDATA-57 T 19 Message Length somewhat confusing.
McDATA-58 E 20 5.3.2 reminder s/b remainder
his wording is confusing. An Auth transaction
is also terminated after the last success frame
McDATA-59 T 20 5.3.1 is received.
There is no such error ReasonCode in the
tables that follow. And why is the "Reason
McDATA-60 E 21 Figure 4 Code" omitted?
Simply configuring a secret will not cause the
Responder to be able to use a different
McDATA-61 T 21 5.3.4 protocol.
No Usable Protocols' doesn't exist in table 14
McDATA-62 T 21 Figure 4 as a valid explanation.
See document 04-394v0 for suggestions
related to Table 15 and Reason Code
McDATA-63 T 22 Table 15 Explanation 09h.
McDATA-64 T 22 Table 14 Change "hash function" to "Hash Function".
McDATA-65 E 24 first sentence Change "password" to "secret".
The bottom line looks dashed and don't know
McDATA-66 E 24 Figure 5 what it means.
Delete word "passwords"
McDATA-67 E 25 Table line with K secret s/b secrets
McDATA-68 E 25 1) reminder s/b remainder
I don't understand this note. The first sentence
in this note and also 3rd paragraph in section
5.4.1 implies supporting DH-CHAP with NULL
DH is mandatory. How can you then not
McDATA-69 T 25 Note 3 include it in the AUTH Neg command?
McDATA-70 E 26 5) Add "As shown by the dashed line in Figure 5,"
Authentication responder s/b 'Authentication
McDATA-71 T 26 5) last sentence Initiator'
Is the "and" at the end of the sentence
McDATA-72 T 26 first sentence suppose to be there?
Support sentence s/b The MD5 Hash function shall be
McDATA-73 E 27 sentence supported for DH-CHAP.
Change "Support.. is mandatory." sentence to
Line starting with "Compliant implementations shall support the
McDATA-74 E 27 "Support.." NULL DHCHAP algorithm."
If different hash functions are required to be
used shouldn't they be listed first? This note is
stating in certain environments you aren't
McDATA-75 T 27 Note 5 required to follow the standard.
Challenge Value Specify what error reason code (RC/E) to use if
McDATA-76 T 29 Length length != 0 and != 16 or 20.
McDATA-77 T 29 DH Value Length Sepcify what RC/E to use if length % 4 != 0.
Is there a way to describe RC/E's more briefly
McDATA-78 E 29 last sentence throughout the document?
Response Value
McDATA-79 T 30 Length Which RC/E to use if not?
McDATA-80 T 30 DH Value Length Which RC/E to use if not?
Challenge Value
McDATA-81 T 31 Length Which RC/E to use if not?
General: Many places in the document have
omissions about what to do if the value says it
shall be such and such value(s). Specify which
Response Value Error Codes and Explanation (RC/E) codes
McDATA-82 T 31 Length should be used or not in all cases?
McDATA-83 T 31 Challenge Value C1 s/b C2
to the first part of the sentence, add "or when
Response Value sent from the Authentication Initiator to the
McDATA-84 T 31 Length Responder".
The way this is laid out almost implies the
AUTH_Done is sent when the signature
McDATA-85 T 33 Figure 6 verification fails.
How verification is performed needs to be
explicitly called out in both paragraphs 3) and
4) or a reference added to the section that
McDATA-86 T 34 3) and 4) does explicitly detail the algorithm.
Inconsistent use of the word
"concatenation". Other algorithms show the
math in formula forms using || for
concatenation.
Adopt a similar style as used in DHCHAP
McDATA-87 E 34 3) section.
McDATA-88 E 34 Note 7 Spell out what "its" refers to.
McDATA-89 T 34 2) Define nonce.
Change to "nonce Ra concatenated with..."
McDATA-90 E 35 first sentence Better yet apply || and formula notations.
second and third change wording from mandatory to "shall
McDATA-91 E 37 paragraphs support"
a) If a unique FCAP certificate type is defined -
it should be coordinated with IETF.
b) For interoperability, there should be a
statement about what existing CA root
certificate SHALL be supported OR
there should be something added to specify
an interoperable CA certificate that shall be
supported.
c) The complete definition of the FCAP
Certificate data structure should be spelled out,
including how ALL fields are to be filled in the
certificate OR
an existing certificate type should be adopted
instead of creating a special one for FCAP.
d) For improved interoperability, it would be
FCAP General desirable to define a mechanism for
McDATA-92 T 38 and Table 33 distributing the CA information.
This data construct should be shown as a
table, indicating the order, size, etc... of all
FCAP X.509 fields as is done in all FC standards. AND add
McDATA-93 T 38 Certificate Value reference to the X.509 document.
The use of letters in this list, imply that the
order of the data is not important. I don't think
FCAP X.509 that is true. What is the order, etc. of
Certificate Value something called Subject Distinguished Name?
McDATA-94 T 38 a), b) etc. Where is the exact data structure defined.
As written is not useful. Say "Contains a
random value of the type shown in Table 35".
Are there important notes that should be added
about the randomness of the value also?
Suggest using verbage similar to verbage
McDATA-95 T 39 Nonce Value found about the Challenge Value in DHCHAP.
There is no easy way to tell what the proper
lengths for the Nonce and Certificate should
be, without a crisper rendition of them in a
table, calling out all optional and/or mandatory
fields to be included in an FCAP Type of
certificate.
Clearly define or put an exact reference to an
McDATA-96 T 39 Table 36 appropriate document.
Authentication
McDATA-97 T 39 Initiator Nonce 'Responder' should be 'Initiator'.
Authentication
Initiator
McDATA-98 E 39 Certificate Cb the s/b Cb of the
Is RSA-SHA1 the same as SHA1 or different?
Not consistent with hash function references
elsewhere in the document. Better to add a
reference to where one can find the spec. for
McDATA-99 T 40 Table 38 RSA-SHA1.
McDATA-100 E 40 Signature Shouldn't "described" be "defined".
Spell out SRP the first time and add it to the
McDATA-101 E 42 SRP abbreviations section.
It appears it is important to know, for the
protocol operations, which mode of operation is
being used, yet I can't find a management
interface that sets the mode policy.
Define a management interface that supports
the FCPAP mode setting and exchanges the
McDATA-102 T 42 FCPAP General policy between switches.
If FCPAP is supported, which mode shall be
supported for interoperability?
paragraph below Add a statement about which mode is optional
McDATA-103 T 42 table to support if supporting FCPAP.
I've found dictionary definitions of the word
"ephemeral" that specify a day or less for the
brief time it exists.
Clarify what a ephemeral "brief amount" of time
should be in an informative note. Is the intent
that the private key should not be stored past
McDATA-104 E 44 2) the time needed for the protocol to complete?
Add clarification that the SALT value should be
a randomly selected number and give
guidance on the minimum length of the random
McDATA-105 T 47 SRP Salt Value number that shall be used.
Here's an example of where SW_ILS may be
used for two different interfaces. If FC SP is to
clearly callout what is the required interface to
5.7.1 first support then there should be a statement
McDATA-106 T 50 paragraph about it.
This is the first place that AUTH_TOV is
McDATA-107 E 52 5.7.3 mentioned.
last sentence of
McDATA-108 E 54 5.8.1 to be s/b that it is
General: "Authentication Transaction" (capital
McDATA-109 E 55 last paragraph T) ?
Is this just a "Authentication Transaction"? If
so, please use that "well-defined term". If not,
would appreciate more details on the
McDATA-110 T 55 last sentence distinction.
First sentence is misleading, since there are
rules restricting which port can be an
McDATA-111 T 55 last paragraph initiator/responder.
2nd paragraph
McDATA-112 E 56 last sentence transaction s/b "Authentication Transaction" ?
Authentication protocol s/b Authentication
McDATA-113 E 56 last paragraph Protocol
is "Authentication protocol message" an
McDATA-114 E 56 last paragraph "AUTH message"???
not sure what "bidirectional" means (or adds to
the text) in this context. Is this an FC-FS term?
(Yes, I can see in Figure 11 that there is a
request Sequence, then a reply Sequence per
Exchange, but this isn't a new or distinctive
McDATA-115 T 56 last paragraph concept in FC).
last sentence of
second Change 'abort' to 'terminate' - otherwise it
McDATA-116 T 56 paragraph could be interpreted as sending an ABTS.
McDATA-117 E 57 Addressing: Add (i.e. well known address for an F_Port)
Add "Authentication of a Fabric Service is
McDATA-118 T 57 b) optional to support."
Need to add that a well known address of a
fabric service could be the S_ID - see case 'b'
for the D_ID. The S_ID and D_ID cases
McDATA-119 T 57 Addressing should be equivalent.
Clarify at beginning section that FC FS defines
the Query Buffer Condition bit for the
FLOGI/PLOGI and the RPBC ELS which are
used to support fragmentation. Further clarify
that FC FS defines the proper response if
RPBC is not supported. Further state that if the
RPBC is not supported that the AUTH_ELS
5.9.4 AUTH_ELS fragmentation flag shall cause the AUTH_ELS
McDATA-120 T 58 Fragmentation to be rejected.
Figure 12 can be confusing depending on
which way you read the example. Usually data
flows from left to right. This implies that the
McDATA-121 E 59 Figure 12 data is flowing from right to left.
Paragraph below Has "security level" been mentioned/defined
McDATA-122 E 59 figure 12. elsewhere in the doc?
second This was confusing until I saw the example in
McDATA-123 T 59 paragraph figure 13.
McDATA-124 E 62 2nd paragraph. s/b "may trigger" ?
first sentence
McDATA-125 E 62 below table 54 to perform s/b of performing
capable to perform Authentication s/b capable
McDATA-126 E 62 of performing Authentication
We should allow an additional option to restart
the protocol instead of re-sending the ELS,
similar to option b) below for AUTH_TOV
McDATA-127 T 62 5.11 timeouts.
Add "F_Ports or Nx_Ports receiving a FLOGI
or PLOGI request shall not send an
AUTH_Negotiate following the receipt of an
AUTH_Negotiate. However, should they do so
(could be an attacker), the sender of the
PLOGI or FLOGI should send an
paragraph below AUTH_Reject with an error
McDATA-128 T 63 table 56 "
Add "Therefore, all implementations need to
use tie-breaking rules in the event of two
AUTH_Negotiate messages being attempted
simultaneously. N-Ports can't rely on sending
their AUTH_Negotiate first, as defined for after
McDATA-129 T 63 5.10 _ a FLOGI, for example."
Change "shall" to "may" in both paragraphs. I
don't think all implementations are going to
McDATA-130 T 63 5.11 support resending the message.
McDATA-131 T 63 Change 'In which case' to 'In this case'.
Change 'but the Requesting Nx_Port does not'
to 'but the Requesting Nx_Port is not capable
of Authentication'. The security bit in the
FLOGI or PLOGI doesn't mean the requesting
Nx_Port requires authentication, but is capable
McDATA-132 T 63 of it.
Change shall to 'may' in last sentence and add
a clause that the protocol may also be
McDATA-133 T 63 5.11 restarted.
McDATA-134 T 63 5.10 Not complete.
McDATA-135 T 63 5.9.5 First paragraph not complete
IKEv2 is not yet an RFC. How can FC SP port
McDATA-136 T 65 6 General a draft?
This needs a high level view of the important
relationships between IKE_SA and Child_SA
McDATA-137 E 65 6 General and other data objects.
General comment. State the purpose of using
IKE clearly in the beginning. Also state
whether to follow IKEv2 developement till it
McDATA-138 T 65 6 General becomes a standard. See next two comments.
It's not clear how to process frames which
need protection. The part equivalent to
McDATA-139 T 65 6 General RFC2401 is missing.
General comment for the whole section. For a
person who is working on IKE (v1), the
referrals to IKEv2 all over the place are
confusing. If IKE is just used as design base
to save time, mention it in the beginnning and
change names with IKE prefix, such as
IKE_SA_INIT, to names with other prefix, such
as SAM_SA_INIT. And change the name of
McDATA-140 E 65 6 General protocol to something like FC Key Exchange.
Preferrable in comparison to last comment, if
the intent is NOT just to use IKE as a design
base to save time (see last comment), and if
the purpose is to port IKE to FC, remove texts
copied from IKEv2 and only explain
terminology/concept mapping and those things
different from IKE must-do lists. The ported
protocol should be refered as FC-IKE or other
name for clarification. The protocol can't be
called IKEv2 unless it implements all the must-
McDATA-141 T 65 6 General do items.
Add terminology from this section, like
McDATA-142 T 65 6 General Child_SA to Definitions clause 3.2.
6.1.1 First
sentence of
second Can't be called a subset if things like message
McDATA-143 T 65 paragraph format is changed.
Clarify what "unique" means to the standard.
Is it illegal to use the same transaction ID that
was previously used during authentication?
6.1.1 third Does the value have to be checked by
McDATA-144 E 65 paragraph implementations for uniqueness?
6.1.1 third Refer to Table 58 that defines the variable
McDATA-145 E 65 paragraph notation.
Explain the notation in figure 15 before
reaching the figure in the document:
[ ] means optional?
{ } means ?
( ) means ?
McDATA-146 E 65 Figure 15 SK means ?
This needs a high level view of the important
relationships between IKE_SA and Child_SA
McDATA-147 T 65 6.1.1 and other data objects.
Clarify what "unique" means to the standard. Is
it illegal to use the same transaction ID that
was previously used during authentication?
6.1.1 third Does the value have to be checked by
McDATA-148 T 65 paragraph implementations for uniqueness?
6.1.1 third
McDATA-149 T 65 paragraph Definitions are incomplete.
6.1.1 third
McDATA-150 T 65 paragraph Reference would be helpful.
McDATA-151 T 65 Figure 15 E payloads are also not shown in figure 15.
Add a picture to portray what the sequence of
different IKE Payloads looks like. Is the order
McDATA-152 E 66 first paragraph important, for example?
Everything in the left column of table 58 should
be added to the Definitions clause.
McDATA-153 E 66 Table 58 Payload type REKEY_SA is missing from table.
Table 58
Description replace "selected by SA_initiator" with
McDATA-154 T 66 column for Sa I. "proposed by SA_initiator"
Table 58
Encrypted
McDATA-155 E 66 notation. Replace E with SK{...} to match usage later
Don't know whether it's intended to differ from
IKEv2. In IKEv2, NOTIFY may appear in a
response of an INFORMATION exchange,
which is after INIT & AUTH. DELETE only
appears in INFORMATION exchange. Only
McDATA-156 T 66 last sentence VENDOR_ID can appear in any message.
Everything in the left column of table 58 should
McDATA-157 T 66 Table 58 be added to the Definitions clause.
McDATA-158 67 6.1.2 title IKE_SA_INIT in not a protocol.
Indicate if there is an order required for the
items supported. (i.e. Does it work like
AUTH_Negotiate, in first ones in list are
McDATA-159 T 67 6.1.2 first para preferred?)
6.1.2 second v3 is not in the reference list. Just X.509. Are
McDATA-160 T 67 paragraph they the same?
Shouldn't T_IDs be the same for request &
McDATA-161 T 69 Figure 16 response?
Vendor_ID may appear in any message in
IKEv2. Putting it here implies it can only
Paragraph below appear in INFORMATION. Make it clear
McDATA-162 T 69 figure 16. where each payload can appear.
Paragraph below
McDATA-163 T 69 note 10. "SPI" has not been defined in this document.
First sentence of
second to last What does "connection" mean in this context?
McDATA-164 T 69 paragraph Is it synonymous with SA?
Change "reserved" to "exchange type" to be
compatible with IKEv2. Guess it's removed
since it already appears in AUTH message?
It's important to keep the message format the
same to claim compatibility.
Same for the "Length" which is supposed to
McDATA-165 T 70 Table 59 follow "message ID" but it's removed here.
Clarify which interfaces these apply to and
McDATA-166 T 70 6.2.1 which interfaces are optional to support.
State any requirements for selection of unique
SPI. For example, can the SPI just be a simple
increment from the last SPI used? What are
the uniqueness requirements for
McDATA-167 T 70 Initiator's SPI ineroperability?
Next IKE
McDATA-168 E 70 Payload Add "(See table 62.)"
IKE Protocol This is out of order with the header table order
McDATA-169 E 71 Version of the fields.
McDATA-170 T 71 6.2.3 Is there an order to this madness?
Duplicate information makes it hard to read. "If
Table 63 bit 7 the recipient does not understand a Payload
McDATA-171 E 73 description type…"
Isn't this subjected to DOS attack as described
McDATA-172 T 73 6.2.4 in 6.8.17?
Exchange in IKEv2 is replaced by protocol,
message, transaction & exchange in this
document. Protocol & message don't describe
it correctly. If exchange can't be used, choose
a right word and make it consistent through out
the document, especially those texts copied
from IKEv2. From IKEv2 exchange there
means: All IKE communications consist of
pairs of messages: a request and a response.
McDATA-173 T 73 6.3 General The pair is called an "exchange".
There's already an overview in 6.1.2. Maybe
McDATA-174 E 73 6.3.1 combine two overviews.
6.3.1 first
McDATA-175 T 73 sentence Remove word "initial".
Change to: Optional Certificate Request
McDATA-176 T 74 Table 64 last row Payload for SA_Responder
McDATA-177 T 74 6.3.2.1 What is a proposal?
McDATA-178 T 74 Note 12 What protocols does this support?
last sentence Conflicts with IKEv2. Change to: is not
McDATA-179 T 75 above Note 14 mandatory…
Do IKE protocol proposals go in the same
McDATA-180 T 75 first paragraph payload?
McDATA-181 T 75 Note 13 This note needs help.
The example proposals show only two protocol
second types. Is a third, IKE, proposal typically
McDATA-182 T 75 paragraph required?
second Where does one look for what is optional for
McDATA-183 T 75 paragraph that protocol?
McDATA-184 T 75 Note 14 Is this note correct?
Table 66
McDATA-185 T 76 reference Where is it?
McDATA-186 T 77 Proposal Length What are the units?
"shall not present" should be "shall not be
McDATA-187 E 78 SPI: present".
Transform type:
McDATA-188 E 78 last sentence Remove NULL.
Don't understand what the last sentence
McDATA-189 E 78 Note 16 means.
What values are legal? Is an SPI of zero
McDATA-190 T 78 SPI: legal?
Since today there is only one Transform
Attribute Type defined there can be only one
attribute. However, doesn't this need a
"number of attributes field" either in Table 68 or
McDATA-191 T 78 Table 68 Table 75. Does this work?
Table 69, value 3
McDATA-192 T 79 Used In cell. Inconsistent with IKEv2.
Integrity of NONE should be optional to
McDATA-193 T 80 Table 72 support.
McDATA-194 T 80 Table 72 Resolve all TBD's.
This conflicts with 6.3.2.2 required transforms
for CT_Authentication. Whatever is chosen,
needs to be compatible with the FC GS
McDATA-195 T 80 Table 72 Note b specification's usage of SHA1.
Since we've ported so much already from the
IKE RFC, why wouldn't we port appendix B info
McDATA-196 T 80 Table 73 also?
The DH values in RFC 3526 are different than
those used for DH Groups ( from RFC 3723) in
the authentication section's table. 3 groups
McDATA-197 T 80 Table 73 overlap.
Table 74 ESP
Header Integrity
McDATA-198 T 81 Mandatory Types Integrity is optional in ESP.
Many places in this document, text that has
been cut and pasted from the IKEv2 spec still
contains references to IKEv2. Should these be
changed to "this protocol"? You might want to
General - last do a global search for "IKEv2" and decide
McDATA-199 E 81 paragraph which need to be changed.
Change the mandatory IKE encryption
algorithm. FC SP does not offer a solution for
encryption/authentication at high speed. Why
do we want to make something Mandatory that
is known to not work with high speed
applications. Also, what is the status of NIST's
McDATA-200 T 81 a) activities and doc 04-245v2?
Wouldn't HMAC_SHA1_160 be a better
McDATA-201 T 81 c) choice?
This seems inconsistent with other parts of
standard that requires support for DH group
McDATA-202 T 81 d) 1536.
McDATA-203 T 81 second a) TBD?
McDATA-204 T 81 second b) TBD?
Conflicts with other parts of this standard, that
says AUTH_HMAC_SHA1_128. The
mandatory algorithm should be what is defined
McDATA-205 T 81 third b) in FC GS.
Make this an informational note, as it is
implementation dependent and only
McDATA-206 T 81 last paragraph suggestions.
McDATA-207 E 82 last sentence "key width" should be "key length".
FC SP should define a standard/interoperable
second way to set the IKE, ESP, and CT suite controls
McDATA-208 T 82 paragraph in clause 7.
McDATA-209 E 83 6.3.2.5 Seems out of place.
McDATA-210 E 84 Note 18 "lengthed" should be "length".
McDATA-211 84 6.3.5 Missing 6.3.5 for Certificate Request Payload.
DH Group Add reference to where the value is defined.
McDATA-212 T 84 Number (Table)
McDATA-213 T 87 padding What determines the encryption block size?
McDATA-214 T 87 pad length add "in bytes"
Add a specific reference for where to find
PKCS#1 and other PKCS# definitions used in
McDATA-215 T 88 Table 85 this standard.
McDATA-216 E 89 4th paragraph "depending from" should be "depending on".
CA third Where does one determine the choices of
McDATA-217 T 92 paragraph certificate types?
McDATA-218 E 94 1st paragraph "composes" should be "compose".
As on page 69, it's not clear what a
McDATA-219 E 95 "connection" is here.
Last sentence
before second a-
McDATA-220 T 98 b list
Add IKE_SA to Definitions along with others
McDATA-221 T 100 SPI: from this clause.
The "initial key" means key for IKE_SA? How
is it used by IKE? Does IKE skip its own
authentication? If so, how? Is more than one
IKE_SA_init in an AUTH transaction allowed?
6.7.1 first Does SA management transaction always start
McDATA-222 T 101 paragraph with IKE_SA_init?
This is very confusing. I assume this AUTH
option means using IKE's own authentication.
If so, why give it another name? If not, what
McDATA-223 E 102 6.7.2 are the differences?
Clarify this. IKE has an authentication
McDATA-224 T 102 6.7.2 message built in.
McDATA-225 E 104 6.8 Good stuff that should be seen sooner in doc.
Clarify why there are two AUTH parameters for
McDATA-226 T 104 6.7.4 FC IKE.
How does it make DOS attack less effective?
When resources are scarce due to the attack,
INIT from valid user will get rejected and have
to retry. The retry would get rejected again
most likely if the system is still under the
attack. The IKEv2 tries to use cookie to
6.8.5 Cookies, differentiate the valid user from the attacker
McDATA-227 T 106 Milk, and DOS when resources get scarce.
Should add the suggestion to use the binary
McDATA-228 T 106 6.8.5 exponential backoff algorithm for retries.
Most of the section is duplicate of 6.3.2 except
McDATA-229 E 107 6.8.6 the last paragraph.
How is rekey handled if authentication & key
management protocol is used to get the key?
McDATA-230 T 107 6.8.7 Can SA get rekeyed w/o reauthentication?
Proposals and Transforms are other important
data construct to add to conceptual model that
needs to be added to the beginning of this
McDATA-231 T 107 6.8.6 clause.
This could lead one to the conclusion that ESP
header and CT_authentication are mutually
McDATA-232 T 107 a) exclusive protocols to be supported.
McDATA-233 T 107 6.8.7 Define what "in place" refers to.
McDATA-234 T 108 third paragraph Define SA bundle.
Which document describes how to maintain
SPD?
When to update SPD with IKE? The example
McDATA-235 T 109 6.8.8 First par. in IKEv2 can't apply here.
Peer SPD consistency is a problem of IPsec.
Packet will get dropped if there's no matching
policy in SPD even incoming packet is
successfully authenticated/decrypted through a
successful SAD lookup. However, 4.7
specifies that frames are passed if there's no
match in SPD. Why does FC need to
McDATA-236 T 109 6.8.8 2nd par. negotiate traffic selector?
Change reference to SPD to a more complete
description of the SPD, including important
behavior and data that will allow
McDATA-237 T 109 6.8.8 interoperability.
For interoperability, a policy should be
McDATA-238 T 109 6.8.8 specified for setting the content of an SPD.
Here is a hint to one thing that must be in an
McDATA-239 T 109 6.8.8 SPD.
6.8.18 second
McDATA-240 T 115 paragraph What is this paragraph trying to say?
Same for the "Length" which is supposed to
McDATA-241 T 120 Table 104 follow "message ID" but it's removed here.
McDATA-242 E 120 Name Length Name Length s/b Hash Length
McDATA-243 T 121 Object Name The term Alphanumeric Name is not defined.
Switch Flags- Should not include the Policy
Data Role here. This would be better
Switch represented as an enumeration (a separate 4
Membership List byte field). It is not really a flag value and as
Object- Switch defined does not leave much room for future
McDATA-244 T 122 Entry expansion.
McDATA-245 E 122 Switch Entry add period to the end of sentence.
This note should be changed to - The Name
McDATA-246 E 122 Table 108 shall be either a Node_Name or a Wildcard.
The if ___ then sentences in this clause should
McDATA-247 E 123 many places be If ____, then
What happens if that one server switch goes
McDATA-248 T 123 last sentence offline? The Client Switch is a half baked idea.
Is it necessary to standardize this bit? It can be
handled by vendor specific methods, if needed.
There is no equivalent policy flag for devices,
McDATA-249 T 124 Auth Tolerance only switches, which is also puzzling.
Authentication Tolerance should be before the
McDATA-250 E 124 Auth Tolerance Authentication Required paragraph.
Switch Memebership List Ordering
Requirements should be at the beginning of
McDATA-251 E 124 7.1.3 this clause - not the end.
Authentication
McDATA-252 T 126 required should "to" be "of"? It makes a difference.
The last sentence s/b s/b by setting the
Authentication Security Bit in the FLOGI LS_ACC (see FC-
McDATA-253 E 126 required FS) to one.
Common
Transport
McDATA-254 E 126 Access Fabric Services s/b Generic Services
In the interest of interoperability and to allow for
minimal implementations,
say "Support for Allow is required if the Device
Membership list policy is supported. Deny may
McDATA-255 T 127 Allow/Deny optionally be supported."
McDATA-256 E 129 Object Name Object Name s/b Switch Node_Name
Number of
Allowed
McDATA-257 E 130 Switches Switch Port_Name field description is missing.
Clarify if the intent is to allow any special
characters other than letters and numbers?
Should identify what characters are supported.
Should it be the same set of characters
supported by Zone Set Names?
Do likewise throughout document for any other
McDATA-258 E 131 Object Name Alphanumeric Name .
Attribute Object This paragraph should go after Basic IP
McDATA-259 E 131 Pointer Management Attributes Format
This table needs to be updated with WKP rows
McDATA-260 E 133 Table 129 instead of GS fields.
The Attribute object defined in section 7.1.7
contains info to use during the authentication
process as defined in the Authentication
Parameters attribute. It defines which switch
should send the negotiate message and which
switch... So the switch does not know if its
policies match with the connecting switch
before running the authentication protocol. Is
McDATA-261 T 134 7.1.7 this a problem?
McDATA-262 E 134 7.1.7 allow to extend this s/b extend the
last sentence of Is there a definition of ascending order? Is this
McDATA-263 T 135 7.1.7 binary or alphanumeric?
This should be moved much earlier in the
document. Shouldn't this be defined in the
same way as other standards? Is this an
McDATA-264 T 136 Alphanumeric improvement?
Need a clear definition of when frame
exchanges used for policy enforcement are
McDATA-265 T 136 7.2 General expected to occur.
Specify which exchanges trigger these checks
McDATA-266 T 137 last sentence and when those exchanges occur.
second
McDATA-267 E 139 paragraph Device Kth Port s/b Device's Kth Port
"appropriate actions shall be performed" is
subjective. How are appropriate actions
managed and defined. This is related to
McDATA-268 T 141 7.2.7 McDATA-24.
Fabric Session is an undefined term. GS uses
server session while SW uses GS Session.
SW has the Fabric Management Session
which can be encapsulated by a server
McDATA-269 T 142 7.3.1 session.
Change name "Fabric Policy Server" to
"Security Policy Server" since FC GS 4 used
that and only this document has to change.
That also resolves the need for getting a new
McDATA-270 T 142 7.3.1 CT Subtype assigned in GS.
McDATA-271 T 144 Policy Object A reference would be helpful here.
This table note should be moved into the
Name field description. One of the "or"s
McDATA-272 E 145 Table 113 should be eliminated.
Attribute Object This paragraph should go after the Basic
McDATA-273 E 145 Pointer Device Attributes paragraph.
managing application s/b management
McDATA-274 E 146 7.3.4.1 application
McDATA-275 T 148 Table 146 Add a description for the Switch_Name
Why are 4 bytes being reserved? Reserved
bytes are usually fill bytes not a whole word.
McDATA-276 T 149 Table 148 Are they obsolete bytes?
The fields in this table need to be defined. The
McDATA-277 T 150 Table 149 Optional should be dropped from Table 150.
Add definition of Total Length field and Security
McDATA-278 T 150 Below Table 149 Object fields.
McDATA-279 T 150 Below Table 150 Add definition of fields.
Does apply mean the switch generates the
McDATA-280 T 150 last paragraph information?
Integrity
Protection Integrity Protection Source s/b Integrity
McDATA-281 E 151 Source Protection Source Name
McDATA-282 E 151 Table 153 title Wrong title? Integrity Protection Tag?
The way fields are described is inconsistent
throughout the document. Some times it starts
McDATA-283 E 151 field descriptions with "Shall be set" other time "indicates".
Is there a reference for how the timestamp is
McDATA-284 T 152 Integer Field defined?
Should say something about how RPO and the
APO command affect the Policy Summary
Object. Is it necessary to activate a new
summary?
Does this just remove the policy from the area
McDATA-285 T 158 RPO/APO that has not been activated?
After Authentication implies that Authentication
McDATA-286 T 160 7.4.1 is required.
Can we be more specific about when the
McDATA-287 T 160 7.4.1 exchange of CPS occurs?
Table 179, Add "or it may be done by vendor specific
McDATA-288 T 163 Fabric Binding. policy".
State when the Zoning Check Protocol occurs
McDATA-289 T 165 par before 7.6.2 during the link initialization.
McDATA-290 T 165 7.6.2.1 GFEZ does not mention FC-SP Zoning.
Zone Set
McDATA-291 T 167 Database Hash How is the hash generated?
ESS:
The ESS protocol may not be very useful for
security protocols. ESS runs after FSPF
because it uses Domain Controller frames.
This should be well after any security protocol
exchanges are completed. The fabric wide
activation protocol has its own method to
detect switches that are down level. Including
the info in the ESS will not hurt but it probably
is not needed.
McDATA-292 E 168 Table 188
McDATA-293 T 168 Bit 9 this Switch s/b this Fabric
McDATA-294 E 168 last sentence equal s/b equal,
McDATA-295 E 168 last sentence in s/b to the
last sentence of
McDATA-296 E 169 first paragraph non s/b not
This value should be assigned by SP and
McDATA-297 T 169 TBD recorded in SW-4.
Zone Set Database Length and Zone Set
McDATA-298 T 171 Below Table 193 Database Object List are not defined in SW-3.
McDATA-299 T 174 7.6.5.1 FSPF distance s/b FSPF cost
How many times do we want to reserve Flags
McDATA-300 T 174 Flags and not use them?
McDATA-301 E 177 8.2 fibre channel s/b Fibre Channel
shouldn't this term be defined in 8.2: "Entity
McDATA-302 177 8.1 Authentication"?
entity s/b Entity ! Likewise capitalize these:
General 8 + 8.2 Security Relationship, Entity Authentication,
second Fabric Entity, Entity Authentication, E_Port
McDATA-303 E 177 paragraph Entity, Nx_Port Entity, Abstract Services
This clause has some major problems that will
be discussed in the next three comments. The
first general comment regards specifying
internal processes that effects implementations
but not external link behavior. This permeates
every transition and we'll pick on 8.6.4.2 as an
McDATA-304 T 177 8 example.
The states in clause 8 need to match state
diagrams from other standards. EEA comes
close but does not mention the P18: Disabled
Port State which was designed for security.
Other states seem more like transitions such
as revoking. Revoking should be a transition
to Disabled, Invalid Attachment or Isolated
depending on the security policy. the
Noncommunicating state works for NNA, but
this state should link to state machines in FC-
McDATA-305 T 177 8 DA and FC-SW-3.
This statement "The criteria for selection and
the means of returning an error are beyond the
scope of this standard; however, subsequent to
issuing such errors, an FNA state machine
shall cause implicit log out of the remote
Nx_Port entity and return to the
noncommunicating state with it." is in multiple
places and misleading. We should define
errors and policies should determine if we do
McDATA-306 T 177 8 implicit logout.
Event and State names are generic and then
redefined each time they are used in the
transitions. Restating NFA_S1 - (i.e.,
McDATA-307 T 177 8 Noncommunicating) becomes cumbersome.
When a port reauthenticates, it should still be
able to carry traffic which is disallowed in the
McDATA-308 T 177 8 first authentication state.
Can the F_Port Can FFFFFE send a LOGO to
a device that it finds unacceptable or should it
McDATA-309 T 177 8 just disable it?
McDATA-310 E 178 c) Nx_Port with Nx_Port s/b Nx_Port to Nx_Port
McDATA-311 E 178 8.3 first sentence Delete "here"
This first sentence is rather confusing. I'm not
McDATA-312 T 178 8.3 sure what it's trying to say.
McDATA-313 T 179 8.4.1 shall s/b should
The intent of this first para is unclear. Maybe a
McDATA-314 179 8.4.2 note could be added describing the intent?
Change this second sentence to something
like this: 'If a fabric name is used, the fabric
McDATA-315 T 179 8.4.2 should present a single fabric entity'.
What about authentication with well-known
McDATA-316 T 179 8.4.2 addresses?
First sentence doesn't sound right. Why can't
an Nx_port establish relationships with more
8.4.2 second than one entity if separate authentication is
McDATA-317 T 179 paragraph used?
Where is the abandon authentication request
McDATA-318 T 180 8.5.2.2 defined?
The intent of this para is unclear. Maybe a
note could be added describing the intent, with
McDATA-319 180 b) examples and counterexamples?
the 2 paragraphs
above 8.4.3 and The intent of this para is unclear. Maybe a
both paragraphs note could be added describing the intent, with
McDATA-320 180 of 8.4.3 examples and counterexamples?
This implies the Nx_Port must authenticate
with the name server to be secure.
Authenticating with the fabric should (or could)
McDATA-321 T 180 first paragraph cover name server communications.
McDATA-322 T 180 8.5.2.1 Add 'or ILSs' after 'ELSs'
McDATA-323 E 181 8.5.2.2 Is this one long sentence? I'ts running on.
The last paragraph says that "the
authentication service reports". Where does it
McDATA-324 T 181 8.5.2.3 report?
McDATA-325 E 181 8.5.2.3 a) Is this referring to an AUTH_Negotiate?
This is not described in the authentication
clause. When is an AUTH_Reject necessary
McDATA-326 T 181 8.5.2.3 b) for reauthentication?
suggest moving the words "to the entity
authentication state machine" following "frame"
McDATA-327 E 181 8.5.2.4 later in the same sentence
Where is spurious traffic event defined? The
format of this spurious traffic event should be
standardized or this reporting should be
McDATA-328 T 181 8.5.2.4 deleted.
The clear security relationships request is not
McDATA-329 T 181 8.5.3.2 defined.
maybe "fabric or shall" would make more
McDATA-330 T 181 8.5.4.2 sense here instead of "fabric and shall"?
Where is the negotiate ELS buffer conditions
McDATA-331 E 182 8.5.4.4 request defined?
McDATA-332 T 182 8.5.4.5 Remove the last "that made the request".
McDATA-333 T 182 8.5.4.8 Change 'port logout' to 'fabric logout'
This implies the Nx_Port can't authenticate any
other Nx_Port unless fabric authentication is
performed (i.e. fabric authentication is required
if any Nx_Port to Nx_Port auth is required).
McDATA-334 T 183 8.5.4.16 a) We shouldn't impose that restriction.
McDATA-335 T 183 8.5.4.16 c) Define 'security frame processing'
Define 'frame that is secured' and how a
McDATA-336 T 183 8.5.4.16 d) receiving port detects it.
McDATA-337 T 183 8.5.4.16 f) Delete 'and is not secured'
McDATA-338 T 184 f) What does it mean to be "not secured"?
Last sentence
before second a- Fx_Ports for the switch s/b Fx_Ports for the
McDATA-339 T 184 b list Switch that require authentication
McDATA-340 T 184 f) Delete 'and are not secured'
Delete this item. This would prevent a re-
FLOGI or re-PLOGI after authentication is
McDATA-341 T 184 h) complete.
Explain how an unsecured FLOGI or PLOGI
paragraph below can be received in an established security
McDATA-342 T 184 I) relationship.
Noncommunicati Why are we defining a new state when we
McDATA-343 T 186 ng have invalid attachment and disabled already?
McDATA-344 T 186 NFA_S3 How do we negotiate ELS buffer conditions?
This should be the revoked state. revoking is a
McDATA-345 T 186 NFA_S6 transition.
This whole clause uses terms that are not
defined properly. For example, A request for
McDATA-346 T 187 8.6.3 login s/b A FLOGI, FDISC or PLOGI
How is this reported? What is the format of the
McDATA-347 T 187 NFA_E4 report? Who is is reported to?
s/b an AUTH_Negotiate is received from an
McDATA-348 T 187 NFA_E7 authenticated client.
What is the nonresponsive state? Is it sending
McDATA-349 T 187 last sentence OLS?
What timeout and counters are being
McDATA-350 T 187 8.6.3 discussed in NFA_E11?
McDATA-351 T 187 NFA_E1 Authentication client is the incorrect term
McDATA-352 T 187 NFA_E3 What is ELS buffer negotiation?
Do we need to standardize that the NFA state
machine internal requests need to be
McDATA-353 T 188 8.6.4.2 specified?
8.6.4.15 first Consistently refer to an easy to understand
McDATA-354 190 sentence name (NFA_S5 - name...).
Says: "The FNA state machine shall be
specified....
....and the NFA state machine shall cause
no action or state change"
Is the above statement referring to NFA state
McDATA-355 191 8.7.1 par 3 machine correctly ?
second
McDATA-356 T 191 paragraph Change 'NFA' to 'FNA'
Delete this event. ELPs are only used with
McDATA-357 T 192 FNA_E1 E_ports.
Says:
"The NNA state machine shall be specified....
....and the NFA state machine shall cause
no action or state change"
Is the above statement referring to NFA state
McDATA-358 197 8.8.1 par 3 machine correct ?
McDATA-359 T 197 Change 'NFA' to 'NNA'
McDATA-360 E 204 8.1 Change 'NFA' to 'NNA'
Add 04-010v6 to letter ballot comment process
McDATA-361 E 205 Annex A for inclusion into Annex A.
In case of a primary SCS failure, the next
backup SCS in the member list takes over the
primary position to guarantee that fabric
management operations are not interrupted."
How do we detect this failure? The Link State
records? How can this be done non-
McDATA-362 T 221 D2.2 disruptively?
McDATA-363 T 221 D2.3 SCC Why isn't DHCHap supported in this?
McDATA-364 E 222 DCC switches ports s/b switch ports
The non-primary SCS switch: determines if the
primary is in the fabric. Does it determine this
McDATA-365 T 224 Stage 2 from LSRs?
"Fabric Management inter-switch frames....
The messages are destined
to either the Fabric Controller (i.e.,
Destination Identifier of FFFFFDh)
or Domain Controller ..."
Clarify that SFC and UFC frames are destined
McDATA-366 E 234 D.3.5 to the Domain Controller.
At
5. Section D.3.6 "Restrict Policy: This field contains a value of
EFMD Request one....."
McDATA-367 E 236 Payload the Title "Restrict Policy should be bold.
D.3.7 Exchange ".....Additionaly, through administration...."
Security Should be
McDATA-368 E 237 Attributes (ESA) ".....Additionally, through administration..."
Change
Notification
McDATA-369 E 240 Definition Remove Change Notification Definition.
Suggested solution
Use current facilitator
Break it up into several sentences and don't
use "protocols" so much.
Write something original.
delete the sentence.
Write English and don't repeat the Foreword.
Do a global search.
This should be different from the intro and
abstract. State some topics that were
discussed and will be placed in SP-2.
Add reference to RFC 3723.
Write a definition but defer authority to the
referenced standards.
Use DHCHAP throughout entire document.
Suggest wording ("size" can mean many
things) which describes the physically-
unenclosed (connected across very long
distances) nature of many fabrics in use
today. Say instead "The growth and variety of
environments in which Fibre Channel fabrics
are deployed makes it difficult…"
Add "secret key" and "shared key" and other
keys (public key? session key?) to definitions.
Use terms about defined types of keys
consistently in text and Figure 1 and
throughout document.
Change to: Secret or password based and
certificate-based authentication
infrastructures are accomodated. OR Define
the difference between secret and password.
Add a section describing Security
Associations.
Add reference to IKEV2 authentication.
delete this paragraph and the a-c list.
Move 4.5 to 4.7 clause and more completely
define SA and SPD.
Do a which hunt throughout the document.
Suggestion: Add a Note indicating the
intention is to allow adjustments of these
definitions in the future when other policy or
policy protocol may be defined.
This may require a way for devices to
advertise their level of support.
Add cross reference to sections detailing
integrity and confidentiality.
Create similar figure for CT Authentication.
Spell the acronym out and add it to the
acronym clause. At least define SPD before
you use it.
Define the interface and behaviors required to
the SPD and the policy for setting an SPD in
an interoperable fabric-wide fashion.
Add a new sentence describing policy
enforcement can happen at any time for
reauthentication purposes or add another
clause to the first sentence.
two places.
add a new section on Security Associations
and discuss traffic selectors.
Change first sentence to: For the initial
connection there are rules for when Fibre
Channel entities act as Authentication Initiator
or Authentication Responder. See 5.9.5 for
Nx_port rules. See 5.7.1 for E_Port tie-
breaking rules. See 5.8.1 for B_Port rules.
Thereafter, for re-authentication, any Fibre
Channel entity may act as an Authentication
Initiator or as an Authentication Responder.
The range of appropriate actions should be
described in a section. If it is, then refer to
that section.
Why is the disabled port state not mentioned
in this standard?
Invalid attachment is only mentioned in
Appendix D. Do a global change to close
communications to reference the new
section. Identify either the Invalid attachment
or disabled state for the purpose of "close
communication".
Clarify that transaction identifier handling
(incrementing to make it unique) applies to all
protocols.
Change it to read "Message Payload".
Maybe the wording should be "and may be
abnorminally terminated with an error
indication by:"
Add reference to table where defined.
Remove the last sentence in the parenthesis.
Change to 'Authentication Mechanism Not
Usable'.
Adopt changes from 04-394v0.
Make it solid or indicate in words the meaning
of the dashed line usage (optional message).
do global search and replace.
If the AUTH initiator prefers other protocols,
those should be listed first and the DH-CHAP
with NULL DH listed last.
Suggest searching for the word "shall"
throughout the document and determine if
values are not those specified whether the
error condition is adequately defined.
Change the drawing so the AUTH_Done and
Calculate Key arrows originate at the same
point.
Use "shall" instead of "mandatory" throughout
the document.
Complete the definition.
Create entire certificate data structure with all
fields specified.
Be consistent when specifying hashes
throughout the document and add reference
to where algorithm being used is specifically
defined.
Specify that 16 bytes of random number shall
be required or other specifics.
E-port to E-port authentication shall be
supported, Domain_Controller to
Domain_Controller authentication is optional.
Define it here or reference the right section.
Use well-defined terms like Authentication
Transaction, Authentication Protocol, etc…
consistently throughout the document.
Reword to something similar to the re-written
authentication overview first sentence in 5.1.
do a globabl search and replace
Use AUTH message terminology?
Delete word bidirectional or define its
importance in the security context in the
Definitions section of the standard.
Make global search and change the use of
word "abort" where appropriate.
Suggested wording is: " See FC FS for a
definition of the related xLOGI Query Buffer
Condition bit and the RPBC ELS. Receivers
of an AUTH_ELS that has the More
Fragments flag bit or the Sequence Number
flag set, when fragmentation is not supported,
shall send an Auth Reject with a reject code
of 0x01, 0x06."
Show the first bit and the last bit in the stream
to clear it up.
Delete words "the security level of"
Might want to clarify that the sequence
number isn't a true numbering of the frames.
It's simply an alternating flag used to interlock
frames between the sender and receiver.
State that receivers "shall" handle retries if
sent, senders "may" send retries.
change this twice
Add "Therefore, all implementations need to
use tie-breaking rules in the event of two
AUTH_Negotiate messages being attempted
simultaneously. N-Ports can't rely on sending
their AUTH_Negotiate first, as defined for
after a FLOGI, for example."
Add "F_Ports or Nx_Ports receiving a FLOGI
or PLOGI request shall not send an
AUTH_Negotiate following the receipt of an
AUTH_Negotiate. However, should they do
so (could be an attacker), the sender of the
PLOGI or FLOGI should send an
AUTH_Reject with an error"
Add the necessary high level concepts and
relationships.
Clearly answer question as to whether IKE is
just used as design base to save time or if the
purpose is to port IKE to FC. Also state
whether to follow IKEv2 development until it
becomes a standard.
Add part that is equivalent to RFC 2401.
Change naming convention to SAM_ and
change name of protocol to FC Key
Exchange.
Clarify whether all IKE RFC's apply, not just
IKEv2. Use more references where practical.
Highlight deviations from must-do lists in
RFC. Change name of ported protocol since
it isn't exactly the same.
Delete reference to "subset".
unique s/b independent and unique from the
authentication transaction
Add to table 58 or add another table for a
legend.
add overview.
unique s/b independent and unique from the
authentication transaction
Add terminology from this section, like
Child_SA to Definitions clause 3.2.
Refer to Table 58 that defines the variable
notation.
Either add to figure or add sentence to that
affect.
Add a picture to portray what the sequence of
different IKE Payloads looks like. Is the order
important, for example?
Use SK{…} notation consistently.
Note deviations from IKEv2 or fix.
Payload type REKEY_SA is missing from
table.
Remove protocol from title.
Clarify the referrence to match the exact
notation used in Reference section.
Clarify.
Clarify.
Define SPI and add reference.
Add "(I.e. SA)" after word connection.
Note deviations from IKEv2 or fix.
Change "between ..." to "between entities".
move it or lose it.
State if there is an order to when payload
types must appear.
Rewrite without repeating as often.
Acknowledge risk in a note or address.
How about using IKE_exchange or i-
exchange instead? And add the IKEv2
definition for "exchange" to the new term
used here.
Have one overview for IKE_SA_Init.
Add "Proposal" to Definitions section and
provide definition for it.
add words "(i.e. CT or ESP protocols)" to
Note 12 or refer to table that specifies
protocols supported OR deleted if NOTE 13
is duplicate information.
A picture of this payload would be helpful,
showing how "Proposals" conceptually fit in
the payload.
Reword to convey what NOTE 12 is trying to
say.
Show IKE proposal example.
Add references to appropriate clauses.
Why would something that can be used,
always be omitted? Clarify NOTE 14.
Correct reference is table 65.
add "in bytes"
Clarify.
Specify legal values for an SPI.
Specify how one knows how many attributes
appear in the Optional Transform Attributes
Definition.
Either add "optional" here or remove
"optional" in the 1st row.
Suggest adding a new transform for
CT_Authentication that matches exactly the
FC GS definition (refer to it).
Add values from Appendix B of IKEv2 draft.
Determine if the same values can be used for
DH Groups in both areas of this standard.
This would make it easier for implementers
supporting both FC SP authentication and FC
IKE. However, there is merit in having IKE
use the same in FC and IP. Having to go
read another RFC should not be necessary in
this case. Add a DH Group table in this
standard for the IKE section, or reference the
DH group table in the authentication section
and add the other DH group values there so it
can be more apparent what to use.
Make integrity optional to be consistent with
IP. OR Add note as to why FC is deviating
from IP optional integrity.
Clean up usage of "IKEv2" or remove term.
Make the ENCR_NULL encryption transform
mandatory to implement until one is available
that works at all speeds.
change to SHA1_160
Change all DH mandatory group usage to
same group.
When this TBD is resolved it should be the
mandatory to support for IKE a) above.
Please determine.
Define or add reference to FC SP clause.
Move this section to the beginning fo 6.3.2.
Add.
Clarify.
Do a global search on all length fields and
specify units of measure.
Add documentation for certificate types
supported.
Fix similarly to McDATA comment for page
69.
Why can't switches do this like in Zoning?
Add text to clarify with references and
answers to the questions.
Pick a better name for using IKE without a
prior authentication protocol.
Clarify that this is referring to the clause 5
authentication prior to SA management
protocol.
Move this section to 6.2.
Add informative note in 6.7.4 reminding
reader that IKEv2-AUTH is expected to be an
unusual case because another authentication
method from clause 5 probably proceeded
the SA Management protocol.
Describe deviation from IKEv2. Add this
scenario.
Add verbage similar to that found in
authentication clause 5 about backoff
algorithm.
Combine 6.3.2 and 6.8.6.
Add clarifications.
Clarify that an IKE_SA for each protocol may
exist at the same time.
Change "in place" to "replacement of an
existing SA without loss of connection or
other SA's"
Define SPD maintenance in FC SP.
Define a standard interface to set the SPD
information in the fabric.
Define the SPD, more completely in this
standard.
please type it into the document.
Make TLVs consistent throughout the
document.
This is usually defined as - A printable ASCII
character string, terminated with a null
character (00h).
Add separate and larger field for expansion of
Policy Data Roles in the future.
This switch behavior should be defined in
SW. There has been minimal coordination
with SW. How do Client Switches initialize?
Can they become server switches? There
are lots of more questions that would have to
be answered. Remove Client Switches.
Make this vendor specific.
move to the front and do a global
replacement of these ordering requirements.
Do global replace
Make Deny functionality optional throughout
the document.
Add Switch Port_Name field description.
Define characters in document before
encountering "Alphanumerical Name"
terminology here.
The fields should be WKP Acces Flags, Well
Known Protocol Number, Well Known Port
Number. These last two fields need to be
defined so that we can check the examples.
please define ascending order.
What is the difference between this and
ASCII characters? Please specify.
Indicate when (for example, after which part
of a connection process?) these are enforced
to ensure interoperability.
In addition to defining the states, we should
have a way to manage actions on a fabric
wide basis. Consistent behavior across all
switches are required.
The various standards need to make this
terminology the consistent and then do a
global replacement of the terms.
Add a reference here to the clause that
describes the Policy Objects.
Delete the reserved bytes.
add field descriptions.
Clarify what is required.
Decide on one format and standardize this
throughout the document.
specify the reference.
Clarify what important interface behavior
required.
Change to: After the authentication stage of
Fabric Initialization, Change 7.6.3.3 too.
Specify after which exchange and before
which part of the process it should occur.
Update reference to GS-5 or delete this. Is
GS-5 considering this?
Reference how the hash is generated or
define it.
Clarify how and when ESS is intended to be
used to support the management interface. If
that was the intent…
This is a fabric wide parameter isn't it?
add comma
next paragraph too.
do global search and replace.
What is trying to be defined? Please clarify.
Is this communism at its worst?
Capitalize globally.
8.6.4.2 could be rewritten simply as: This
transition occurs when event NFA_E1
(i.e., a request for login is received from an
authentication initiator) is received.
This avoids discussion of FC-2 , internal
subsystem calls, timers, and requests.
Have a subgroup rewrite Clause 8 with
connections to other standards and states
with proper references.
Define the errors for various scenarios so that
we have predictable behavior.
Use only the shortened names (e.g.,
revoking) or a state name so that we don't
have to repeat both every time.
Add a new state for reauthentication to allow
traffic to flow while it is reauthenticating.
Allow FFFFFE to send LOGO for a graceful
degradation. This will affect many transitions
and errors in this clause.
please clarify.
Aren't we authenticating the physical link that
several virtual abstractions can use?
Different Virtual N_Ports could have different
security requirements. Likewise, different
virtual fabrics on the same port could have
different security requirements. This will be
determined by individual policy.
Should external fabric services be
authenticated to the fabric? Please specify or
allow.
Clarify or rewrite the sentence.
Please define it.
Change this clause to indicate its up to the
fabric whether it requires authentication with
WKAs.
Parse this into a couple of sentences.
If it reports it to internal software, we don't
need to write about this in this standard.
Clarify
please define or delete.
Clause 8 refers to many internal requests and
other things that should not be discussed or
defined in this standard. The standards
should only concern themselves with frames
and protocols that travel on the link. This
problem occurs in 8.5.4.2 (N_Port Login
Request), 8.5.4.11 - 16. Should we even
mention FC-2?
Add reference to FC FS.
Does it mean to be authenticated? If so, then
this statement is redundant. Either way, we
should define what it means to be secured
This modifier is needed since not all Fx_Ports
need to do this.
Change noncommunicating to match SW's
states. This applies to Figure 28 as well.
I thought we did this with FLOGI and RPBC.
If so, then we could say that. This might be
one of those internal states that should not be
in the standards. Same for NFA_E3
This applies to FNA_S6 as well.
Do a global search and deletion of reporting if
it is internal.
Do a global search and replace with the
proper term.
Please specify.
change client to other terminology throughout
the document.
Add ELS buffer negotiation to Definition
clause and describe it as optionally using the
RPBC ELS as described in FC-FS.
Delete these internal processes from the
standard. Again in 8.6.4.5.
Delete third paragraph on page 193 as well.
Complete Annex A.
Please specify how this is detected and how
the next switch in the list takes over control of
the application non-disruptively.
Add DHCHAP to the list of authentication
protocols.
Please specify how.
Add "The SFC, UFC, etc. are destined to the
Domain Controller." to the end of the
paragraph above table A.22.
Change Restrict Policy: to bold characters.
Fix typo.