FCIP conf call minutes - 090501

["Murali Rajagopal" <muralir@lightsand.com>]

FC over TCP/IP conference call minutes:

Date: 09/05/01

Minutes submitted by: Raj Bhagwat

Attendees:

Don Fraser
Ken Hirata
Larry Lamers
David Peterson
Anil Rijhsinghani
Neil Wanamaker
Ralph Weber
Vi Chau
Gaby Hecht
Milan Merhar
Venkat Rangan
Bob Snively
Raj Bhagwat
Murali Rajagopal

I apologize if I missed anyone else.

Minutes:

1. Carrying the discussion to the IPS list

- Murali indicated that Elizabeth likes to see more FCIP related discussion
taking place on the IPS list.
- Larry felt that people in the IPS list need to know what is being
discussed.
- Venkat will post the security proposal to the IPS list. Ralph indicated
that the IPS list has the people with expertise in security and their
feedback will be helpful.
- There was discussion on whether Venkat's security proposal should be a
separate draft. Murali indicated that it can be a separate draft initially
but will be eventually absorbed in the main FCIP document.

2. Conf calls for next two weeks

- Next week's conf call will be set up by Compaq (Don Fraser). The conf call
will be on Thursday (9/13/01), 1.30PM to 3.30PM PST.
- Cisco (Dave Peterson) to set up the conf call for the following week.

3. TCP connection management

There was a brief discussion the interaction that should happen between FCIP
Entity and FC Entity when a TCP connection is closed. This was a follow up
to the discussion that took place through email. Ralph indicated that the
FCIP Entity needs to inform the FC Entity when a TCP connection is closed.
It was also noted that, if FC Entity wants to close a connection, it may not
be able to tell the FCIP entity whether it should be through a RST or FIN.

4. Security

The rest of the conf call was mostly spent on discussing Venkat's proposal
on security.

- Venkat's proposal is similar to what iSCSI has decided on security.
However, iSCSI has not made any decision on whether to support Tunnel mode
or Transport mode. FCIP is leaning towards Tunnel mode.
- Venkat said that the choice of IKE and Tunnel mode is in line with what is
currently supported on most of the external IPSec gateways. This will be a
helpful if FCIP devices need to be integrated with external security
gateways to comply with FCIP requirements.
- Larry indicated that IKE and Tunnel may not work with NATs. IPSec group is
expected to resolve this.
- Larry said that, for FCIP, authentication should be at machine level and
not user/application level. Bob/Venkat clarified that IKE Phase1 is at IP
address level, but IKE Phase 2 is at port level.
- Venkat provided couple of clarifications - (1) Multiple FCIP end points
(LEPs) sharing same Phase 1 negotiation is not prohibited. (2) More than one
pair of FCIP end points can share the same security policy.

Murali and Venkat summarized the different choices proposed in Venkat's
document. They are reproduced here from Murali's email to the IPS reflector.

a. Keying Recommendation: Per RFC2409
        - IKE with pre-shared keys MUST implement
        - IKE with public-key based keys MAY implement
        - IKE Main Mode MUST implement
        - IKE Aggressive Mode MAY implement

b. Integrity MAC
        - HMAC-SHA1 MUST implement
        - AES in CBC MAC mode with XCBC extensions SHOULD implement

c. Confidentiality
        When used:
        - 3DES in CBC mode MUST implement
        - AES in CTR mode SHOULD implement
        When not used:
        - NULL Encryption [RFC2410]

d. Encapsulation Modes
        - Tunnel Mode/Transport modes being discussed, with bias to Tunnel
Mode.

The discussion on security continued...

- Anil had questions on SA. He suggested having SA for each link instead of
each connection. Venkat indicated that, as currently proposed, each
connection will have a separate SA. Anil said that external gateways
associate SA at IP address level. He suggested keeping FCIP security model
close to how it exists on external IPSec gateways.

Section 9.2, bullet 4 - It was felt that this bullet is not adding anything.
Decided to take it out.

Page 2, last paragraph - Can be dropped since it is confusing and not
necessary.

Section 9.3.3 -  The current proposal suggests rekeying after 2^31 sequences
are exhausted. Murali asked why it is so conservative. Murali was concerned
about scaling it to 10G. Larry indicated that the IP Security group is
currently looking into extending the sequence number to a larger value and
probably there will be a solution by the time we have 10G.

Section 9.3.3, last paragraph - Bob indicated that FCIP_DE will never see
IKE traffic since it is handled at a layer below IP layer. Venkat had
concerns that in the diagram (fig. 5), the IP connection is shown attached
to the FCIP_DE. May be, we need to clean up the diagram. Decided to remove
this paragraph.

6. Ken Hirata asked if single connection can support multiple classes. Bob
said it is allowed.

7. Discussion on Ralph/Bob's proposal to get through NAPTs

There was some discussion on the proposed solution. Larry felt that using
reserved bits would be a better solution than using SOF/EOF encodings. Here
is the summary taken from Ralph's email:

1) Do something with the reserved bits (or one
bit) that identifies the proposed frames?

2) Change the SOF/EOF words 7 & 13 to the
Reserved/-Reserved format.

3) Find a name other than NOP for the
frames. I hereby suggest FCIP Short Frame.


-----------------------------------------------
Raj Bhagwat
LightSand Communications, Inc.
Ph: (949)837-1733, x104
http://www.lightsand.com