|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] FCIP WG Last Call - Technical Comments Proposed Resolutionshttp://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ips-fcip-wglc-00.pdf Contain the proposed resolutions show below for technical comments that are not related to security. If you want to discuss any of the proposed resolutions please start a new reflector message thread for each comment to be discussed and include the comment number in the message subject. Thanks. .Ralph 1. Comments from David Black ========================= Comment 28 Technical -- Section 6.4 - FCIP Entity The interfaces to the IP Network features is implementation specific, however, to maintain interoperability, the notable TCP/IP mechanisms used are specified in this document as follows: [E] I'd rephrase this to talk about "REQUIRED functional support" and remove the "to maintain interoperability" language. Accepted with the following results 1) Change "is" to "are"; 2) Replace everything from "however" to the end of the cited text with: "however, REQUIRED TCP/IP functional support is specified in this document, including:" Comment 34 Technical -- Section 6.6.2.2 - Errors in FCIP Headers and Discarding FCIP Frames In addition to the tests above, the validity and positioning of the following FCIP Frame information SHOULD be used to detect encapsulation errors that may or may not affect synchronization: a) Protocol # field and its ones complement (2 tests); b) Version field and its ones complement (2 tests); [... list continues, snipped ...] [T] I think at least these two are MUSTs. At a minimum, the Protocol# and Version field must be checked against expected values - I might accept the checks against their ones complements being SHOULDs. Same comment applies to the Flags field and SOF. Someone MUST check the FC frame CRC before forwarding the frame, but that responsibility could be assigned to the FC Entity. Accepted (Partially) with the following results 1) Add to 6.6.2.2 checking Protocol# and Version#. This addition will have to be in a separate paragraph before the current 1), 2), 3) list because it is not a synchronization issue; 2) Keep the one's complement tests in the SHOULD a), b), c) list, but reduce the number of tests in that list by 2 (1 in a and 1 in b); and 3) Change the count of optional tests required from "5 of 18" to "3 of 18". Responses to other issues raised by comment a) The Flags field is not a MUST test because it provides no certain identification of the protocol beyond that provided by the Protocol# field; b) Explicit testing of the SOF and EOF values is not MANDATORY in this section because they must be used to reconstruct the FC Frame prior to transmission in the FC Fabric. That process will necessarily validate the SOF and EOF; and c) Not even the Fibre Channel standards require that the FC CRC be validated by FC Fabric elements. FC Endnode validation of the FC CRC is sufficient. Comment 35 Technical -- Section 6.6.2.2 - Errors in FCIP Headers and Discarding FCIP Frames At least 5 of the 18 tests listed above SHALL be performed. Failure of any of the above tests actually performed SHALL indicate an encapsulation error and the frame SHALL NOT be forwarded on to the FC Entity. Further, such errors SHOULD be considered carefully, since some may be synchronization errors. [T] There aren't 18 tests, and I think some of the individual tests (or subsets) are MUSTs (see previous comment). This needs to be gone over carefully - in essence a MUST is only appropriate where failure to apply the test carries a non-negligible risk of forwarding a bad frame to FC. The authors are the experts on this and need to do this analysis. I don't understand the last "SHOULD" - what is the (testable) requirement on an implementation? No changes made There are 18 tests: 2 + 2 + 1 + 2 + 2 + 1 + 4 + 1 + 2 + 1 = 18 What tests are MUSTs is covered by comment 34. The authors have gone over the tests carefully and have concluded that no individual test or specific group of tests associates specifically with a non-negligible risk of forwarding a bad frame to FC. The requirement is that a suitable number (at least 5, or 12 when the 7 required tests are included) tests is necessary to reduce the risk of forwarding a bad frame to FC to a negligible level. The specific tests selected depends on the implementation, i.e., what test can be performed most efficiently in the implementation hardware. The "SHOULD" statement is intended to guide implementations. Repeated failures of, for example, the CRC equal to zero test may mean that synchronization has been lost. There are no hard and fast rules here. Comment 36 Technical -- Section 6.6.2.3 - Synchronization Failures If the FCIP_DE attempts to recover synchronization, the resynchronization algorithm used SHALL meet the following requirements: [T] One requirement is missing, which may be part of b): b) return to sending valid FC Frames only after synchronization has been verified; and [T] Verification of synchronization MUST exclude any possibility of forwarding an FC frame that was not sent by the transmitting FCIP Entity. This includes the scenario in which a valid encapsulated FCIP frame occurs in the payload of an FC frame that is encapsulated and sent over FCIP; excluding this scenario is necessary but not sufficient to meet the requirement. Accepted with the following results Replace b) with: "return to forwarding FC Frames only after synchronization on the transmitted FCIP Frame stream has been verified; and" Comment 37 Technical -- Section 6.6.2.3 - Synchronization Failures An example algorithm meeting these requirements can be found in annex C. [T] That doesn't meet the missing requirement that my above comment wants to add. The problem is at step 2 of the algorithm description. 2) Use multiple strong candidate headers to locate a verified candidate header: The Frame Length in one strong candidate header is used to skip incoming bytes until the expected location of the next strong candidate header is reached. Then the tests described in step 1) are applied to see if another strong candidate header has successfully been located. The "skip incoming bytes" step makes it possible that a set of valid FC headers is interlaced in the payloads of FC frames in a fashion that causes all the real headers to be skipped. This is a rather unlikely, but not impossible scenario. This could be dealt with by searching for headers instead of skipping data and aborting if a header is found where data should have been or carrying on and aborting if an interlaced header chain scenario arises. The algorithm in Annex C does address the scenario of FCIP frames occurring in FC frame payloads, but it doesn't meet the "can't be fooled" requirement that I think should be added. Unfortunately, this issue appears to not be resolvable within the WG. I have had heated and lengthy offline discussion with the FCIP Authors in which they have made clear their strong opposition to the "missing requirement" and the need to scan rather than skip data, and have argued that the algorithm in Annex C produces a long enough chain of headers that the odds of having followed a chain that is interlaced through frame payloads is small enough to be ignored. I will have to consult the Area Directors. Accepted with the following comment Modifications to either step 2 or step 3 will achieve the requested results. Because step 3 already includes complex steps such as verifying the FC CRC value, changes in response to the comment will be made in step 3. Actions to be taken 1) Change the first paragraph of Annex C step 3 from: "Incoming bytes are skipped and discarded until the next verified candidate header is reached. Each verified candidate header is tested against the full collection of tests listed in section 6.6.2.2 as would normally be the case." to: "Incoming bytes are inspected and discarded until the next verified candidate header is reached. Inspection of the incoming bytes includes testing for other candidate headers using the criteria described in step 1. Each verified candidate header is tested against the tests listed in section 6.6.2.2 as would normally be the case." 2) Change the second sentence in the third paragraph of Annex C step 3 from: "If any verified candidate headers are invalid and fail to meet the tests for a strong candidate header, increment the retry counter and return to step 1." to: "If any verified candidate headers are invalid and fail to meet the tests for a strong candidate header or inspection of the bytes between verified candidate headers discovers any candidate headers, increment the retry counter and return to step 1." Comment 38 Technical Section 7 - Checking FC Frame Transit Times in the IP Network The FC Entity MUST implement the measurement of Fibre Channel frame IP Network transit time as described in the FC Frame Encapsulation [27] specification. [E] "MUST implement" --> "MUST implement and use" for clarity. Accepted but not as the comment intended The statement is misleading and needs to be revised. Action to be taken Replace the cited sentence with: "FC-BB-2 [4] defines how the measurement of IP Network transit time is performed, based on the requirements stated in the FC Frame Encapsulation [27] specification. Additional note See comment 40 for a discussion of why IP Network transit time checking is done by the FC Entity. Comment 40 Technical Section 7 - Checking FC Frame Transit Times in the IP Network The FC Entity SHALL use suitable internal clocks and either Fibre Channel services or an SNTP Version 4 server [13] to establish and maintain the required synchronized time value. The FC Entity SHALL verify that the FC Entity it is communicating with on an FCIP Link is using the same synchronized time source as it is, either Fibre Channel services or SNTP server. [T] I don't believe that this paragraph meets the requirements in the FC Frame Encapsulation specification for processing transit time information. Punting this up to the FC Entity is problematic - the minimum functional requirements on the FC Entity to meet the FC Frame Encapsulation requirements will need to be spelled out here in detail (i.e., a single sentence saying "must meet requirements in Section 4 of the FC Frame Encapsulation document" is probably not going to fly). Mallikarjun caught some issues in this area also. Rejected The decision to move time validation from FCIP to FC-BB-2 was made for sound technical reasons: 1) Having the FC Entity verify transit time makes the test more end-to-end; 2) Class F frames need not have their transit time verified. That decision is allowed by the FC Frame Encapsulation. Encoding that test in FCIP would necessitate a substantial increase in the FCIP reliance on FC specific knowledge, including but not limited to cracking FC Frames; 3) Allowing Class F frames to transit without transit time verification is required to allow the FC Time Service to be used as a source of synchronized time, a critical feature for the success of FCIP; and 4) The description of the interactions between the FC Entity and FCIP Entity for the purpose of maintaining a synchronized time based on the FC Time Service were getting impossible to verify for correctness when the requirements were stated in FCIP. Having the FCIP Entity perform transit time tests was in the FCIP draft as recently as draft-ietf-ips-fcovertcpip-05.txt. The requested organization was tried and proved to be unworkable. Comment 43 Technical -- Section 8 - The FCIP Special Frame The Connection Usage Code field contains Fibre Channel defined information regarding the intended usage of the connection as specified in FC-BB-2 [4]. [T] The authors need to talk to me about this, so that I can understand what's going on here, and whether we need another IANA registry, as is the case for the SOF and EOF values. No changes made The Connection Usage Code field allows pairs of FC Entities to communicate 16-bits of connection setup information in the Special Frame. It represents a request that the FC-BB-2 side of the house made on the FCIP side. Given that FC-BB-2 is defining a whole new SW_ILS to support a request made in the reverse direction, it is difficult to see why the presence of the Connection Usage Code field is an issue. Comment 44 Technical -- Section 8 - The FCIP Special Frame [T] This section needs to describe the usage of the FCIP Special Frame, including the structure of the interaction between the two FCIP Entities, and how that establishes the security and connection usage properties that are desired. The descriptions in Section 9 contain a great deal of detail that mixes several mechanisms together - a high level guide to what's going on is necessary to understand them. Accepted with the following results It is considered desirable to leave the Special Frame open to additional uses in future versions of FCIP. This is why Section 8 lacks the requested overview. Actions to be taken 1) Put the current Section 8 text in 8.1 "Special Frame Format"; and 2) Add 8.2 "Overview of Special Frame Usage in Connection Establishment" Comment 46 Technical -- Section 9.1.2.1 - Non-Dynamic Creation of New TCP Connections If the TCP connect request is rejected, the FCIP Entity SHALL act to limit unnecessary repetition of attempts to establish similar connections. [T] That's a little vague. How about specifying a minimum time period that MUST elapse before retry? Rejected The purpose of the statement is to recommend against denial of service to other TCP clients as the result of over jealous attempts to retry rejected TCP connect request by FCIP Entities. In the absence of an explanation of how interoperability is affected, it not possible to devise a requirement that is both specific and practical for implementations. Comment 52 Technical -- Section 9.1.3 - Processing Incoming TCP Connect Requests If the Destination FC Fabric Entity World Wide Name contains 0, the FCIP Entity SHALL take one of the following three actions: 1) Leave the Destination FC Fabric Entity World Wide Name field and Ch bit both 0; 2) Change the Destination FC Fabric Entity World Wide Name field to match FC Fabric Entity World Wide Name associated with the FCIP Entity that received the TCP connect request and change the Ch bit to 1; or 3) Close the TCP Connection without sending any response. The choice between the above actions depends on the anticipated usage of the FCIP Entity and is outside the scope of this specification. The FCIP Entity may consult the "shared" database when choosing between the above actions. [T] I'm not buying the "outside the scope" disclaimer. Some more description of why the three choices are available is in order even if the normative criteria for choosing among them are specified in FC-BB-2. If my assumption about FC-BB-2 is correct, the last sentence is almost certainly too weak - it needs to refer to consulting the FC Entity to determine what to do. Accepted but not as the comment intended Delete "... and is outside the scope of this specification" Other actions to be taken Note: Some non SLP implementations wish to use the SF as a configuration determination mechanism. The choice exists to allow that option. Describe this in the new section added in response to comment 44. Comment 53 Technical -- Section 9.1.3 - Processing Incoming TCP Connect Requests If: a) The Destination FC Fabric Entity World Wide Name contains a non-zero value that does not match the FC Fabric Entity World Wide Name associated with the FCIP Entity that received the TCP connect request, or b) The contents of the Connection Usage Flags, and Connection Usage Code fields is not acceptable to the FCIP Entity that received the TCP connect request, then the FCIP Entity SHALL take one of the following two actions: 1) Change the contents of the unacceptable fields to correct/ acceptable values and set the Ch bit to 1; or 2) Close the TCP Connection without sending any response. [T] 1) looks like a security hole that discloses information an attacker may find useful in establishing an undesired connection to FCIP. What's the motivation/purpose for this? No changes made The motivation is to allow the SF to be used as a poor-man's SLP. Option 1) is a security policy that is not a security hole because either IPsec or option 2) or both are available as security policy choices. Comment 54 Technical -- Section 9.1.3 - Processing Incoming TCP Connect Requests If the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier field values in the FCIP Special Frame match the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier associated with an existing FCIP_LEP, the FCIP Entity SHALL: 1) Request that the FC Entity authenticate the source of TCP connect request, providing the following information to the FC Entity for authentication purposes: [T] Need to say more about what the FC Entity MUST do to "authenticate the source". I realize that the details are specified in FC-BB-2, but the functional requirements on the FC Entity can be specified here. Accept but only to a limited degree Requiring the FC Entity to do a specific thing in response to the request to authenticate goes substantially beyond the security policies that the IETF applies to itself (i.e., this would be MANDATORY to implement and MANDATORY to use). Action to be taken Replace the "warning" paragraph cited in comment 56 with: "The definition of the FC Entity SHALL include a mechanism for use in response to a TCP connect request source that communicates with the partner FC Entity on the FCIP Link using a previously authenticated TCP Connection to verify that the Connection Nonce has been sent in a yet to be completed TCP Connection setup. Failure of the partner FC Entity to verify the Connection Nonce SHALL be treated as an authentication failure." Comment 55 Technical -- Section 9.1.3 - Processing Incoming TCP Connect Requests The FCIP Entity SHALL wait indefinitely for the FC Entity to authenticate source of the TCP connect request and SHALL not use the new TCP Connection for any purpose until the FC Entity completes the authentication. [T] "wait indefinitely" creates an obvious denial of service attack vulnerability. Try again. Rejected The potential for a denial of service attack exists only if the attacker can affect the interface between the FCIP Entity and the FC Entity. Since the interface between these two exists only inside an FCIP-FC implementation, the opportunities for such an attack are reasonably beyond the bounds of such concerns. If the FCIP Entity and FC Entity were specified in a single standard, the wording would be "Do A, B, and C." There would be no interface point at which a wait could exist and the issue would either be handled implicitly (probably with R_A_TOV) or ignored entirely. Comment 57 Technical -- Section 9.1.3 - Processing Incoming TCP Connect Requests Note that the originator of TCP connect requests uses IP Address and TCP Port to identify which TCP Connections belong to which FCIP_LEPs while the recipient of TCP connect requests uses the Source FC Fabric Entity World Wide Name, Source FC/FCIP Entity Identifier fields from the FCIP Special Frame to identify which TCP Connection belong to which FCIP_LEPs. For this reason, an FCIP Entity that both originates and receives TCP connect requests is unable to match the FCIP_LEPs associated with originated TCP connect requests to the FCIP_LEPs associated with received TCP connect requests. [T] That's a problem. See comment against Section 9.1.2.1 for one suggestion for how to fix this, but some sort of fix appears necessary to me. Rejected see comment 124 Comment 60 Technical -- Section 9.3.4 TCP_NODELAY Option FCIP Entities SHALL set the TCP_NODELAY option to one. This will disable the Nagle Algorithm that is designed for usage in a telnet environment. [T] I believe that "SHALL" should be a lower case "should". This is a local performance optimization that has no other effects. Accepted Comment 61 Technical -- Section 9.5 - Flow Control Mapping between TCP and FC Coordination of these flow control mechanisms one of which is credit based and the other of which is window based depends on painstaking design that is outside the scope of this specification. [T] This is content-free. At least warn about some of the things that can go wrong, in particular BB-credit starvation and the potential to really screw up a Fibre Channel fabric if this is long-lived. Rejected This text was written in specific response to the decision of Orange County interim meeting that "The only statement that should appear in FCIP on the subject is, 'There be dragons here.'" Comment 84 Technical -- Annex A - IANA Considerations [T] Instruct IANA to change the authority for those port allocations to reference this RFC when it is approved. Add a sentence forbidding the use of UDP with FCIP even though IANA has allocated a port. Accepted 2. Comments from Mallikarjun Chadalapaka ===================================== Comment 109 Technical > 6.6.1 FCIP Encapsulation of FC Frames .... > The CRCV (CRC Valid) Flag SHALL be set to 0. > > The CRC field SHALL be set to 0. I am surprised that the FCIP encapsulated header is never protected by a CRC. The error detection section clearly acknowledges the possibility that TCP checksum could be inadequate for certain deployments - and even suggests checking the FC frame CRC (sort of like a data digest) on reception at the Encapsulated Frame Receiver Portal. My recommendation is to require an FCIP Entity to employ the header CRC if the SF that it receives asks for CRC - IOW, similar to iSCSI's approach. So, I guess I am also advocating a new bit in the pFlags field to announce this. When this CRC expectation is announced, the FC CRC checking test in 6.6.2.2 should also be a mandatory test - from the "semi-optional" list it is currently in. Rejected The SF is protected by requiring that the echoed data field values exactly match those sent. This is an end-to-end-to-end check that is more certain than even a CRC. Comment 117 Technical > 7. Checking FC Frame Transit Times in the IP Network .... > ... If no synchronized time stamp value is available to > accompany the entering FC Frame a value of zero SHALL be > supplied. From this, it isn't clear to me if FCIP *requires* only Synchronized operation. If so, the draft should also specify how implementations are expected to deal with "benign" transitions into and out of the Unsynchronized state (i.e. transitions happening when no Encapsulated Frames are being received). Rejected Class F frames can be transmitted and forwarded in the Unsynchronized state. The requirements for transit time determinations are in FC-BB-2 for all the reasons described in the response to comment 40. Comment 128 Technical > 9.1.3 Processing Incoming TCP Connect Requests...... > abort the TCP connect request [8]. If the requested connection is I was told that "abort" isn't available on all implementations - perhaps "abort/close" would be better.... Accepted with the following results Change "abort the TCP connect request [8]" to "reject the connect request using appropriate TCP means" Comment 131 Technical > 9.1.2.3 Connection Setup After a Successful TCP Connect Request ...... > 2) Change the Destination FC Fabric Entity World Wide Name field > to match FC Fabric Entity World Wide Name associated with the > FCIP Entity that received the TCP connect request and change > the Ch bit to 1; or In effect, this is being indirectly allowed as a legal discovery process. Is there a DoS concern here? Also, would revealing the FC WWN be acceptable in confidentiality terms? Duplicate of comment 53. 6. Comments from Ralph Weber ========================= Comment 140 Technical The bit/byte numbering resolution approved for the FC Frame Encapsulation draft must be replicated in this draft. Accepted Comment 141 Technical In order to support the FC-BB-2 Link Keep Alive (LKA) switch internal link service, it is necessary for FC/FCIP Entities to communicate a time interval for transmission of the LKA. The T11 FC-BB-2 working group has asked that this 32-bit quantity be added to the Special Frame. Accepted
Home Last updated: Thu Apr 11 15:18:20 2002 9607 messages in chronological order |