RE: FW: Redirection (was UNH Plugfest 5)

["Rod Harrison" <rod.harrison@windriver.com>]

I agree with Paul that the spec should be specific on this. At this weeks
plugfest none of the 16 companies present had the ability to configure this
behaviour so the reality is the first set of products are going to go out hard
coded in this manner and some are not going to interoperate. Right now many
products are ready to go when the RFC is published and it's too late to rework
GUIs, configuration databases and config app to device protocols. The result is
going to be that authentication will be unusable with targets that redirect.

I personally would like to see the spec say authentication MUST complete before
redirection can occur, but like Paul I can accept either choice.

A possible way out here is to go with the same approach chosen for the extension
digests, that is mandate either redirection before or after authentication
unless there has been explicit administrator intervention. That gives
interoperability with implementations that can't configure this behaviour, and
gives an out for those that want the choice the standard doesn't mandate if they
are prepared to do the configuration work.

- Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Paul Koning
Sent: Friday, January 17, 2003 2:22 PM
To: Julian_Satran@il.ibm.com
Cc: Black_David@emc.com; ips@ece.cmu.edu
Subject: Re: FW: Redirection (was UNH Plugfest 5)


>>>>> "Julian" == Julian Satran <Julian_Satran@il.ibm.com> writes:

 Julian> David, The only way to do it cleany the way you want it is to
 Julian> allow the redirect response (0101 and 0102) only in
 Julian> operational parameter stage.  But that seems rather
 Julian> excessive. If we want to mandate a single way of handling I
 Julian> would suggest stating that 0101 and 0102 SHOULD be accepted
 Julian> even during authentication (Paul's POV). Again I don't thing
 Julian> it adds anything as local policy may prevent an initiator
 Julian> from considering those values.

"SHOULD" is helpful in that at least it gives a recommendation.  But
it is not good enough.

We want to build targets that interoperate with all initiators.  Right
now, the spec simply does not permit us to achieve this goal.

I've expressed a preference in how things would work, but it doesn't
matter a whole lot which way things go.

Right now, we have an implementation that will issue a redirect before
completing the full authentication handshake.  Most initiators accept
this, but some do not.

We're perfectly willing to change it so the target does complete the
whole authentication handshake, and only then sends the redirect.  But
we're afraid to do so because the spec does not require initiators to
accept that either!

So we're faced with a known interop problem, and if we change the
behavior to the other possible way we are at risk of running into
other initiators that don't like doing things THAT way.

So pick one, but it MUST be a MUST.

1. An initiator MUST accept a redirect from a target that has
   completed the authentication handshake; it MAY (or SHOULD) accept
   it from a target that has not yet completed the handshake.

or

2. An initiator MUST accept a redirect from a target that has not yet
   completed the authentication handshake; it SHOULD (or MAY) accept
   it from a target that has completed the handshake.

Well, of course there's a third alternative, which is to require that
both alternatives MUST be accepted.  I do not propose that but would
not object to it.

    paul