Re: FCIP: Comment 120

[Ralph Weber <ralphoweber@compuserve.com>]

Mallikarjun,

The more I think about this:

> Besides, I don't see anything in the current document that prohibits multiple
> FC/FCIP Entity Pairs from sharing the same IP/TCP address/port - and I believe
> that is the right architectural approach.

the less I like it.

This seems like a poorly disguised attempt to force FCIP off its
design center, which is a collection of statically (or near statically)
configured FCIP Link endpoints.

Call FCIP hardware-centric if you like, but the idea that an FCIP
Entity controls its connection points through the IP Addresses and
Ports it announces (via SLP or otherwise) is fundamental to the
design and currently specified algorithms.

The idea that one first connects to a IP Address/Port and then
decides which FCIP Entity within it really wants to talk to
flies in the face of SLP usage, and (while Venkat is the security
expert not me) it seems like a potential security hole of the
highest magnitude. I seriously believe that this breaks the
authentication mechanism recently added to FC-BB-2 in support
of multiple TCP Connections in a single FCIP Link.

As I have noted before, the purpose of the Destination FC Fabric 
Entity World Wide Name field is to say, "This is the FC Fabric Entity 
I think I'm talking to; hang up if that is wrong." In other words,
the field serves as a check on the correctness of the IP Address
and Port used to make the TCP Connection.

The purpose of the field as currently designed definitely is not to 
say, "This is the FC Fabric Entity I want to talk to." That would
be using the FSF as an extension of the IP Addressing mechanism,
when all the FSF was ever intended to do is replace IP Address 
as an FCIP Entity identifier.

Surely, such a profound change in the design basis for FCIP 
connection setup, has implications that resonate far beyond
adding a field here or there or changing the usage of some
existing fields.

This path is bogus. It is inconsistent with substantial parts
of the current FCIP draft. If followed, it calls into question
the FCIP usage of SLP, IPsec, IKE, and goodness knows what else.
It is not "the right architectural approach". It is more like
trying to build a pagoda using Roman columns.

.Ralph

"Mallikarjun C." wrote:

> > I would think that sending a TCP connect request to the same IP Address
> > and Port as was used in the previous TCP connect request would achieve
> > the intended result.
>
> Not a correct assumption.  You are using names (FC Fabric Entity WWN is
> a name.  The FC/FCIP Entity Identifier is a name unique within the scope of
> the FC Fabric Entity.) in FSF only because IP addresses/TCP port associations
> cannot provide the FCIP-end2end assurance that the right entities are talking.
>
> Besides, I don't see anything in the current document that prohibits multiple
> FC/FCIP Entity Pairs from sharing the same IP/TCP address/port - and I believe
> that is the right architectural approach.
> --
> Mallikarjun
>
> Mallikarjun Chadalapaka
> Networked Storage Architecture
> Network Storage Solutions Organization
> Hewlett-Packard MS 5668
> Roseville CA 95747
> cbm@rose.hp.com
>
> ----- Original Message -----
> From: "Ralph Weber" <ralphoweber@compuserve.com>
> To: <ips@ece.cmu.edu>
> Cc: "Mallikarjun C." <cbm@rose.hp.com>
> Sent: Wednesday, May 08, 2002 6:26 AM
> Subject: Re: FCIP: Comment 120
>
> > "Mallikarjun C." wrote:
> >
> > > Upon further thought, it appears to me that the "Destination FC/FCIP
> > > Entity Identifier" should be sent and received in the FSF.  I can not
> > > think of a way currently to build an FCIP_LEP with multiple FCIP_DEs
> > > - for ex., how would a sender indicate his intention to add a TCP
> > > connection to an FC/FCIP Entity Pair that it's already communicating
> > > with?
> >
> > I would think that sending a TCP connect request to the same IP Address
> > and Port as was used in the previous TCP connect request would achieve
> > the intended result.
> >
> > The only alternative would be to REQUIRE SLP interrogation before every
> > TCP connect request, and even then there would be zero assurance that
> > the IP universe would not shape shift between the SLP activities and
> > the TCP connect request.
> >
> > Surely, there is some stability in IP addressing.
> >
> > Thanks.
> >
> > .Ralph