On Tue, 6 Jan 2004, Mallikarjun C. wrote:

> Let me attempt to answer Joe's questions and clarify
> a couple of Pat's points.

And I'll comment on your comments. :-)

> On Joe's #1, I agree with Pat's comments - there is no
> need to return valid values of sequence numbers before
> the final successful login reponse.

Note: Joe was talking about MaxCmdSN and ExpCmdSN, and I agree there is
some question about them. However you mentioned "sequence numbers", which
can be taken to include StatSN too. As best I can tell, StatSN needs to be
present and respected at all times. Also, our target expects StatSN (and
ExpStatSN) to be handled correctly even in login. As StatSN is
connection-specific, I see no session nor security problems with this. :-)

I think perhaps we should split this question into two questions. 1) what
should the target put into MaxCmdSN and ExpCmdSN (and the initiator into
CmdSN), and 2) what should the target (or initiator) do with the CmdSN
(MaxCmdSN and ExpCmdSN) value(s) it gets.

I think (2) is the more important. I think both the initiator and target
should ignore CmdSN, MaxCmdSN, and ExpCmdSN on PDUs other than the last
one. For the initial login and for session reinstatement, I think the
CmdSN on the last Login Request (the one that triggers the transition to
FFP) should seed the target's idea of ExpCmdSN (and thus MaxCmdSN). Other
than that, I think it should be ignored. As login commands are immediate,
that makes sense.

As for (1), I think you're supposed to be shoving good values into the
response. Our target does. However with (2) in place, it wouldn't hurt if
the target just returned zero.

Does anyone see a security implication of the target leaking MaxCmdSN and
ExpCmdSN?

> On Joe's #2, Joe said:
>    "My inclination is to only consider the connection to be part of the
>     connection when it has successfully completed the entire login
>     sequence, and thus do connection reinstatement just prior to sending
>     the last login response."
>
> This is indeed the intent.  Connection reinstatement
> should be performed only when the target is ready to
> signal the final approval for the login attempt on the
> connection in question.  A target cannot perform the
> reinstatement for an old CID instance unless it arrived
> at a new FFP connection with the same CID (clearly, I
> think, stated in 5.3.4), i.e. unless login process is
> successfully complete for the new instance.

Agreed.

Actually, we have two levels of session membership. One is "full" which a
connection gets when it goes to FFP. This is what everyone thinks of for
connections being in a session.

The other is a tentative membership, which we give new connections that
are members of an existing session. This isn't really covered in the spec.
We do this mainly so that we can limit the number of connections tied to a
session, and protect ourselves from DoS attacks. A connection in this
state can see what's happening in the session (it reports MaxCmdSN and
ExpCmdSN), but it can't impact the session. This is how we send back valid
MaxCmdSN and ExpCmdSN.

You can only have MaxConnections connections in FFP, and MaxConnections +
a fudge factor (currently 2) connections in FFP and in login.

> On Joe's #3, the general approach should be to allow
> new login attempts to proceed as long as the total
> number of connections is < MaxConnections.  At the
> time the target moves a connection to FFP, it should
> consider any earlier instance of the same CID to have
> been reinstated and drop the old instance (10.12.7).
> I thus would not recommend the approach you're leaning
> towards.  Note however that the 10.12.7 text assumes
> that the initiator is well-behaved - if the initiator
> is in fact launching multiple login requests at the
> same time for the same CID, then it's violating the MUST
> requirement in 10.12.7 - "The initiator connection
> state MUST be CLEANUP_WAIT (section 7.1.3) when the
> initiator attempts a connection reinstatement."

We take a third approach. If we don't already have MaxConnections + 2
connections in FFP and in login, we let a new login proceed. If we didn't
do something like this, then if you had a session with MaxConnections
connections, you could not do any ERL 2 recovery.

We let the second (connection reinstatement) login attempt proceed as
well.  When ever either of them reaches FFP, both the original connection
and the login that hasn't completed login get killed.

Yes, this is a violation in that the initiator appears to be violating
10.12.7. However if something went wrong with one reinstatement attempt,
we might get to this situation.

> On Pat's points -
>
>  > "Successful connection/session reinstatement" might be
>  > read to mean that the login for the new session successfully
>  > completed rather than just a login request was received.
>
> Yes, as clarified above.

Agreed. It all happens at the end of login processing, just before the PDU
is sent indicating we're going to FFP.

>  >However note that a failed connection
>  > reinstatement causes T15 which moves the session from LOGGED_IN to
>  > CLEANUP_WAIT so a failed attempt would still disrupt an active
>  > connection.
>
> True, that was intended.  However, there are two state
> machines here (CSM-C and CSM-I, borrowing 7.2 terminology),
> and note that Pat's clarification applies to CSM-C (i.e.
> the state machine representing the old instance).  The CSM-I,
> the new state machine the login is happening on, OTOH,
> takes the T7 transition from IN_LOGIN to FREE.
>
> A "failed connection reinstatement", however, should have
> been defined in the spec (as Pat says).  For a connection
> reinstatement effort to be considered "failed" and thus
> cause a state change to CSM-C on the target end, the effort
> should have progressed (and failed) beyond the SecurityNegotiation
> stage.  Ditto for session reinstatement.

Take care,

Bill

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips