Re: FCIP Last Call, comment 109 - Special Frame

[Ralph Weber <ralphoweber@compuserve.com>]

David,

Regarding:

> That [always closing the TCP connection if the SF data changes]
> would be fine if the received data were always discarded when a 
> change occurred that caused connection closure.  My understanding
> of the "poor man's SLP" scenario is that the received data is intended
> to be used even though the connection was closed.  TCP-grade data
> integrity may be ok for that use - if that's the case, a single
> sentence saying that as part of the new description of "poor man's
> SLP" should be sufficient to close this issue.

I have no problems with adding the requested sentence.

However...

I believe that your understanding of the "poor man's SLP" scenario
continues to reflect a misunderstanding of the intrinsic checks
that it contains.

When the "TCP-grade data" is used after the connection is closed,
the only practical use is to place it in the SF sent on the
next TCP connection. When that is done, the "TCP-grade data" is 
subjected to the full validation requirements (correct values and
properly replayed response) that are applied to first time data.
Wrong values are wrong values are wrong values, regardless of
source: TCP or bogus data in the sender's "shared" database.

I can think of no conditions wherein wrong SF values of the
type that "poor man's SLP" can introduce are allowed to conclude
with an operational TCP connection.

In particular, the objective of "poor man's SLP" is to determine 
the identity of the destination of the TCP Connect request, for 
placement in the next SF. If the identify information is altered 
by TCP, the next SF will contain wrong information that the 
destination is certain to be able to detect (after all the 
destination has unquestionable knowledge of its own identity).

The process is far more air tight than the stated concerns
suggest.

Thanks.

.Ralph

Black_David@emc.com wrote:

> > Regarding:
> >
> > > Comment 109: The proposed resolution says:
> > >
> > >    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.
> > >
> > >         Unfortunately, comments 52 and 53 call out text that allows
> > >         those fields to be changed.  This needs some more thought/
> > >         explanation, and this issue needs to be considered open for
> > >         now.
> >
> > Yes, the fields are allowed to be changed and such changes result
> > in the connection being closed 100% of the time. Whether the changes
> > are intentional or accidental, the connection is ALWAYS closed if
> > the SF fails to transit back and forth unchanged.
> >
> > The ONLY way the connection is NOT closed is when the SF transits
> > both directions unchanged, NO EXCEPTIONS.
> >
> > I believe that this fully maintains the integrity of the end-to-end
> > check described in the comment response.
>
> That would be fine if the received data were always discarded when
> a change occurred that caused connection closure.  My understanding
> of the "poor man's SLP" scenario is that the received data is intended
> to be used even though the connection was closed.  TCP-grade data
> integrity may be ok for that use - if that's the case, a single
> sentence saying that as part of the new description of "poor man's
> SLP" should be sufficient to close this issue.
>
> Thanks,
> --David
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
> black_david@emc.com         Cell: +1 (978) 394-7754
> ---------------------------------------------------