|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] iFCP: Responses to David Black iFCP Technical review comments
Comment 4. [T] Section 2.1, Definition of FC-4 Layer
"FC-4 - The fibre channel application layer. This layer is
functionally equivalent to the TCP/IP application layer."
I don't understand this. Are you equating FC-4 with OSI layer
7? If so, I'm not sure that is correct, and it might be better
to leave out this attempted analogy.
Accepted
The definition will be changed to:
"FC-4 - The fibre channel mapping of an upper level protocol,
such as [FCP-2], the fibre channel SCSI mapping."
Comment 5. [T] Section 3.2, page 10
a) "Arbitrated Loop -- A series of N_PORTs connected together
in daisy-chain fashion. Data transmission between N_PORTs
requires arbitration for control of the loop in a manner
similar to a token ring network."
That's not a fabric topology, unless the loop is fabric
attached, in which case you're in case c), Mixed Fabric. iFCP
can't support an FC-AL loop that isn't fabric-attached.
Accepted in part
The terminology will be changed to "fibre channel network
topologies". However, like existing FC switch products, an iFCP
gateway can emulate an FC-AL loop environment. The gateway does
this by representing remotely attached devices as if they were
resident on a local loop.
The specification will be modified to describe such
configurations. In addition, the following definition will be
added:
"Fabric -- From [FC-FS]: "The entity which interconnects
N_PORTs attached to it and is capable of routing frames by
using only the address information in the fibre channel frame."
Comment 6. [T] Section 3.2, page 11, para 5
"Depending on the topology, the N_PORT and fabric port variants
through which a fibre channel device is attached to the network
may be one of the following:
"Fabric Topology Fabric Port Type N_PORT Variant
--------------- ---------------- --------------
Loop L_PORT NL_PORT
Switched F_PORT N_PORT
Mixed FL_PORT NL_PORT
F_PORT N_PORT"
I believe the Loop line in this table does not match the other
lines and if so, this is one more reason to leave non-fabric-
attached FC-AL out of this description.
Accepted in part
Since the loop topology can be supported, it should remain in
the table. However, the terminology should be changed per
Comment 5 and the table modified as shown below:
"FC Network Topology N_PORT Variant FC Network Interface
-------------------- -------------- --------------------
Loop NL_PORT L_PORT
Switched N_PORT F_PORT
Mixed NL_PORT FL_PORT via L_PORT"
In the case of a mixed fabric, additional supporting text will
be provided.
Comment 9. [T] Section 4.4 - iFCP Fabric Properties
At some point the need to reuse 24-bit addresses for outbound
traffic from a single FC link behind an iFCP gateway will be a
problem. This comment also applies to the second paragraph in
Section 4.4.2.
Accepted
A discussion of address re-use issues will be added to the
spec.
Comment 11. [T] Section 4.5, pp 24, para 14
"The mode of gateway operation is settable in an
implementation-specific manner. The implementation MUST NOT
allow the mode to be changed after the gateway begins
processing fibre channel frame traffic."
Might want to add a MUST that a gateway cannot operate in more
than one mode at the same time, and a repeat of the (implied)
requirement that all gateways in an iFCP fabric MUST operate in
the same mode.
Accepted
Comment 12. [T] Section 4.6. pp 24, para 2
b) "When interoperating with locally attached fibre channel
switch elements, each iFCP gateway MUST assume control of
DOMAIN_ID assignments in accordance with the appropriate
Monia, et-al Category - Expiration [Page 6]
Responses to iFCP Revision 10 Last Call Comments April 2002
fibre channel standard or vendor-specific protocol
specification."
This is ok, but turns up another requirement that needs to be
explicitly stated earlier. Any given FC N_PORT MUST NOT be
behind more than one iFCP gateway. Address Transparent mode
satisfies this because only one gateway can become the
principal switch, so the others presumably shut down, but
Address Translation mode appears to have the potential for
seriously nasty misbehavior unless the "iFCP gateway MUST
become the principal switch" requirement is imposed on it also.
Need to add a sentence or two on how an iFCP gateway can be
assured of becoming the principal switch. Beyond this, the
fact that any Fabric Attached FC-AL loop can have only one FL
port completes the picture, ensuring that a loop can't stitch
two gateway domains together. Requiring the iFCP gateway to be
the principal switch also avoids problems with the gateway
being unable to obtain sufficient Domain IDs from the principal
switch.
Accepted in Part
For either iFCP fabric type, an N_PORT may be behind more than
one gateway provided:
a) One gateway becomes the 'principal switch' and
b) All gateways attached to a given gateway region coordinate
the assignment of N_PORT IDs and N_PORT aliases such that
each N_PORT has one and only one assigned address.
The above will be added to the specification.
Comment 13. [T] Section 5.2.2.2, pp 32, para 4
"The gateway SHALL initiate the creation of an iFCP session in
response to a PLOGI ELS directed to a remote N_PORT from a
locally attached N_PORT as described in the following steps.
a) "Using the D_ID field in the PLOGI frame header, locate the
remote N_PORT descriptor. If no descriptor exists, the iFCP
gateway SHALL return a response of LS_RJT, with a Reason
Code of 'Unable to Perform Command Request' (0x09) and a
Reason Code Explanation of 'Invalid N_PORT_ID' (0x1F). An
iFCP session SHALL NOT be created."
Need to explain why this is ok.
The answer is that a properly operating FC N_PORT will have
previously issued an FC nameserver query that the gateway
translated to an iSNS query, and hence when it issues PLOGI to
the result of the nameserver query, the iSNS query response
created the required descriptor in the gateway before being
translated to the FC nameserver result. There's an implication
here that remote N_PORT descriptors that result from iSNS
queries translated from FC nameserver queries MUST NOT be
discarded as long as any N_PORT that has issued a query for
that remote N_PORT is logged into the fabric.
Accepted in part
Although a name server query is almost always done in practice
prior to a PLOGI, an N_PORT compliant with [FC-FS] is not
required to do so. For that reason, the specification should
cover the case where a fibre channel device attempts to send
frames to an address without having executed a previous name
server query.
Also, while the policies for remote N_PORT descriptor retention
are implementation-specific, the specification should at least
contain recommendations. In that regard, the following added
text is proposed:
"Remote N_PORT Descriptors should be reclaimed based on a last
in, first out policy.
"An iFCP implementation should have sufficient resources to
insure that a newly created descriptor is not reclaimed before
the referencing iFCP session is created."
Comment 17. [T] Section 5.2.2.2 - Creating an iFCP Session
There's no discussion of what to do if a TCP connection closes
unexpectedly during this process (e.g., if closing of unbound
connections is allowed at arbitrary times for reasons such as
reducing the resources consumed by unbound connections). This
needs to be added even if the reason in parentheses is not
allowed.
Accepted
Comment 18. [T] Section 5.2.2.2, pp 35, para 4
"Upon receiving such a request, the gateway providing the
connectivity probe SHALL transmit LTEST messages at the
specified interval."
This requires liveness test (LTEST) messages even when the
connection is in active use. Was that intended?
Response
The intent is to require LTEST messages at the specified
interval regardless of whether or not there is other traffic.
Comment 20. [T] Section 5.2.3.1, pp 38, para 1
"In response to the Unbind message, either gateway may choose
to close the TCP connection or return it to a pool of unbound
connections."
This assumes that Unbind is always successful. It can fail, as
documented in Section 6.2. Need to specify how to deal with
this (e.g., close the TCP connection).
Accepted
The sentence will be modified as follows:
"Upon successful completion of an Unbind operation, either
gateway may choose to close the TCP connection or return it to
a pool of unbound connections."
The processing for the failure cases will also be specified.
Comment 21. [T] Section 5.2.3.1 - iFCP Session Completion
Can an iFCP gateway reduce the pool of unbound connections
(e.g., due to demands for resources for other connections),
possibly by closing them? If yes, need to say so.
Accepted
A gateway may close an unbound connection due to resource
demands. The spec will be modified appropriately.
Comment 23. [T] Section 5.4.1, pp 40, para 1
"Protocol# IANA-assigned protocol number identifying
the protocol using the encapsulation. For iFCP the value is
(/TBD/)."
It's 2 - cite the FC Encapsulation draft's IANA Considerations
section as the authority for this.
Accepted
Comment 25. [T] Section 5.4.2 - SOF and EOF Delimiter
Fields
"SOF (bits 31-24 and bits 23-16 in word 0): iFCP uses the
following subset of the SOF fields described in [ENCAP].
This is a problem because these codes are being specified in
more than one place. I think the FC Frame Encapsulation
document is the right place for the normative specification of
these codes (and see my comments against it on the need to get
IANA involved). This would be ok as a list of codes that are
currently valid, but the specification authority needs to be in
one place. Same comment applies to EOF.
Accepted in Part
The specification will be revised in accordance with Comment
24.
Comment 27. [T/E] Section 6 - TCP Session Control Messages
Monia, et-al Category - Expiration [Page 11]
Responses to iFCP Revision 10 Last Call Comments April 2002
Request LS_COMMAND Short Name iFCP Support
------- ---------- ---------- -----------
Connection Bind 0xE0 CBIND REQUIRED
Unbind Connection 0xE4 UNBIND REQUIRED
Test Connection Liveness 0xE5 LTEST REQUIRED
[T/E] How do we know that those three values (E0, E4, and E5)
will not conflict with some future usage by Fibre Channel? I
think the answer is that SES=1 in the iFCP flags in the header,
and would be 0 in any future use of these values in an ELS, but
the use of those three values looks like an attempt to avoid
conflict and should be explained.
Accepted
That is correct. These values were chosen as patterns readily
distinguishable by a protocol analyzer.
Comment 28. [T] 6.2 - Unbind Connection (UNBIND)
"Unbind Status Description
------------- -----------
0 Successful û No other status
1 - 15 Reserved
16 Failed - Unspecified Reason
18 Failed - Connection ID Invalid
Others Reserved
"Unbind can fail, but earlier specification of the use of
Unbind (e.g., in Section 5.2.3.1) assumes that it cannot fail."
Description of how to deal with Failed status needs to be added
there (e.g., close the TCP connection).
Accepted
Comment 31. [T] 7.3 - Fibre Channel Link Services Processed
by iFCP
"The following Extended and FC-4 Link Service Messages must
receive special processing."
Process question - how does this list get coordinated with T11
so that it gets updated when T11 defines a new ELS or FC-4 LS
that requires iFCP intervention?
Response
The specification must be revised to track the evolving fibre
channel specifications, including, among other things, the
addition of new link services that require special processing.
Comment 32. [T] 7.3.1.1 - Abort Exchange (ABTX)
"Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- section 7.2) ------------
-----------
Exchange Originator 1, 2 N/A
S_ID"
Need to specify how to choose the translation type. This
comment also applies to RES, RES ACC, RLS, RSS, RRQ, RSI, REC
and REC ACC. It may be best resolved by adding additional text
in Section 7.2.
Accepted
Comment 35. Section 8.2.1 - Enforcing R_A_TOV Limits
The rules in this section appear to allow forwarding of all
frames received while in Unsynchronized mode or with a
timestamp of 0,0. This looks like formula for violating
R_A_TOV - was this intended?
Response
The intention was to abort all iFCP sessions and not allow the
creation of new ones. The specification will be revised
accordingly.
Comment 36. [T] Section 9.4.1 - Establishing the Broadcast
Configuration
"The broadcast configuration is managed using facilities
provided by the iSNS server. Specifically:
a) "An iSNS discovery domain is created and seeded with the
network address of the global broadcast server N_PORT. The
global server is identified as such by setting the
appropriate N_PORT entity attribute."
There are no means for recovery from failure, so loss of the
gateway performing the broadcast service results in loss of the
broadcast service. This needs to be explained at a minimum, and
probably corrected.
Accepted
An implementation may designate a local server as a standby
global broadcast server. The local server uses the LTEST
message to determine if the global server is functioning and
may assume control if not.
The specification will be revised accordingly.
Comment 37. [T] Section 10.2.2, page 82, para 1
"Conformant implementations of the iFCP protocol MAY use such
security definitions."
I don't understand this sentence. What was intended?
Accepted
The paragraph will be changed to:
"It is imperative to thwart these attacks, given that an iFCP
gateway is the last line of defense for a whole fibre channel
island, which may include several hosts and fibre channel
switches. To do so, the iFCP gateway must implement and may use
confidentiality, data origin authentication, integrity, and
replay protection on a per-datagram basis. The iFCP gateway
must implement and may use bi-directional authentication of the
communication endpoints. Finally, it must implement and may use
a scalable approach to key management."
Comment 38. [T] Section 10.2.3, pp 82, para 1
"Enterprise data center networks are considered mission-
critical facilities that must be isolated and protected from
all possible security threats. Such networks are usually
protected by security gateways, which at a minimum provide a
shield against denial of service attacks. The iFCP security
architecture is capable of leveraging the protective services
of the existing security infrastructure, including firewall
protection, NAT and NAPT services, and IPSec VPN services
available on existing security gateways."
While this is true of iFCP, iSNS has some serious issues with
NAT and NAPT and iFCP cannot be operated without iSNS.
Rejected
iSNS issues with NA(P)Ts are thought to be resolved (see
Section 3.6 in the iSNS specification). iSNS has at least two
non-exclusive options to cope with NA(P)Ts, a) the use of FQDNs
instead of IP addresses, and b) the option to establish a
confederation of iSNS servers and have them doctor IP numbers
in transit as part of their mutual confederation contract.
Comment 39. [T] Section 10.2.4, pp 82, para 1
"iFCP gateways MUST use Discovery Domain information obtained
from the iSNS server [ISNS] to determine whether the initiating
fibre channel N_PORT should be allowed access to the target
N_PORT. N_PORT identities used in the Port Login (PLOGI)
process shall be considered authenticated provided the PLOGI
request is received from the remote gateway over a secure,
IPSec-protected connection."
Need to say something about the IKE identities (ID payloads)
used for the authentication, and how they correspond to
information obtained from iSNS - NATs/NAPTs will cause issues
here. Just requiring an IPsec-protected connection isn't good
enough as it may allow a node not registered with iSNS to get
in.
Accepted in part
It would be premature to enumerate ID payloads in section
10.2.4, which describes the scope of the overall security
design prior to any IKE/IPsec requirement (to follow in
sections 10.3). The requested information will be supplied
after the last paragraph in section 10.3.1.
Regarding intervening NA(P)Ts between iSNS clients and servers,
it is possible to put a proxy iSNS server at the boundary
between addressing domains. Such proxy will terminate the
IKE/IPSec so that the ID_IPV4_ADDR identity can be used
natively by IKE. It is also possible to use the second method
described in the response to comment 38 -- a confederation of
iSNS servers where the NAT(P)T mediation now occurs between
iSNS servers.
Admission control is performed by the iSNS server, based upon
the Discovery Domain (DD) configuration information stored in
that iSNS server. Once the authenticity of a gateway is
verified (e.g., via a pre-shared key) and IPsec SAs are
established, then the gateway is trusted to behave according to
the specification, which mandates a handshake with iSNS for
admission.
Comment 41. [T] Section 10.2.7 Authorization
"Authorization is outside of the scope of this specification,
and is seen as fully orthogonal to the iFCP security design.
Such design, however, includes key authorization-enabling
features in the form of Identity Payload (e.g., ID_FQDN),
certificate-based authentication (e.g., with X509v3
certificates), and discovery domains [ISNS]."
What?? If iSNS doesn't know about an iFCP gateway, that
gateway shouldn't be able to talk to any other iFCP gateway.
That's access control, which counts as authorization in my
book.
Accept
The paragraph will be re-written as follows.
"Basic access control properties stem from the requirement that
the communicating iFCP gateways be known to one or more iSNS
servers before they can engage in iFCP exchanges. The optional
use of Identity Payloads (e.g., ID_FQDNs), certificate-based
authentication (e.g., with X509v3 certificates), and discovery
domains [ISNS] enables authorization schemas of increasing
complexity. The definition of such schemas (e.g., role-based
access control) is outside of the scope of this specification."
Comment 43. [T] Section 10.3.2, pp 86, para 9
"Upon receiving an IKE Phase-2 delete message, there is no
requirement to terminate the protected TCP connections or
delete the associated IKE Phase-1 SA. Since an IKE Phase-2 SA
may be associated with multiple TCP connections, terminating
such connections might in fact be inappropriate and untimely.
An iFCP Portal must instead attempt to create a new Phase-2 SA
while there are outstanding iFCP sessions."
That's a problem. If the other side is behaving in accordance
with the next paragraph ...:
"To minimize the number of active Phase-2 SAs, IKE Phase-2
delete messages may be sent for Phase-2 SAs whose TCP
connections have not handled data traffic for a while. To
minimize the use of SA resources while the associated TCP
connections are idle, creation of a new SA may be deferred
until new data is to be sent over the connections."
... and is deleting the Phase-2 SAs because it lacks the
resources to support them, immediately creating a new Phase-2
SA in response to delete messages risks livelock (massive churn
in Phase-2 SA creation/destruction). Creating a new Phase-2 SA
in response to a Phase-2 delete message SHOULD be deferred
until there is traffic to send over that SA.
Accepted
We shall be removing the misleading sentence "An iFCP Portal
must instead attempt to create a new Phase-2 SA while there are
outstanding iFCP sessions." and promote from may to SHOULD
prior to the word 'deferred'.
The resulting modified text is shown below:
"Upon receiving an IKE Phase-2 delete message, there is no
requirement to terminate the protected TCP connections or
delete the associated IKE Phase-1 SA. Since an IKE Phase-2 SA
may be associated with multiple TCP connections, terminating
such connections might in fact be inappropriate and untimely.
"To minimize the number of active Phase-2 SAs, IKE Phase-2
delete messages may be sent for Phase-2 SAs whose TCP
connections have not handled data traffic for a while. To
minimize the use of SA resources while the associated TCP
connections are idle, creation of a new SA SHOULD be deferred
until new data is to be sent over the connections."
Comment 45. [T] Section A.2 - Link Services Processed
Transparently
"ACC Accept"
Is that right? I thought this was intercepted in some cases,
as indicated in Table 6.
Response
The ACC description will be modified to discriminate between
the transparent and non-transparent cases.
Comment 46. [T] Section A.2 - Link Services Processed
Transparently
FDISC Discover F_Port Service Parameters
FLOGI F_Port Login
RTV Read Timeout Value
Definitely wrong - the iFCP gateway has to implement these
itself as specified in Section 9.1.
Accepted in Part
Special link service messages are those which require
intervention by an iFCP protocol implementation before they are
passed to the destination N_PORT. Transparent link service
messages are passed to the destination N_PORT without such
intervention. In that regard, the above link services are
processed transparently.
The specification will be modified to make the above
distinction clearer and the section will be re-titled as: "Link
Services Processed Transparently by the iFCP layer".
Comment 47. [T] Section A.2 - Link Services Processed
Transparently
LINIT Loop Initialize
LPC Loop Port Control
LSTS Loop Status
SCL Scan Remote Loop
I don't have time to check these, but I'm suspicious about
whether anything that has "Loop" as part of its name can/should
be forwarded transparently into an FC fabric, although SCL
seems plausible. Please verify whether these are transparent.
Response
SCL must be processed as a special link service message. iFCP
will be modified accordingly. The remaining link services
listed above are transparent.
Comment 48. [T] Section A.2 - Link Services Processed
Transparently
RSCN Registered State Change Notification
SCN State Change Notification
SCR State Change Registration
Those can't be transparent, as Section 9.2 requires the iFCP
gateway to implement them.
Response
See response to Comment 46.
Home Last updated: Tue May 07 15:18:27 2002 10002 messages in chronological order |