RE: USM time windows check question

Inline

> -----Original Message-----
> From: Bob Natale [mailto:[email protected]]
> Sent: zaterdag 4 januari 2003 9:38
> To: [email protected]
> Subject: USM time windows check question
> 
> 
> Hi,
> 
> In considering RFC3414 Sec 3.2.7b, I am curious
> as to whether the ordering of the sub-sections
> 1) and 2) has any significance...?  That is,
> is that ordering supposed to indicate that the
> tests and actions in 1) should be performed
> first and then the tests and actions in 2) should
> be performed...?
> 
I think so, as I think all the steps are to be executed 
in the sequence as documented. It is maybe possible that 
other sequences are valid too... but we have all been 
evaluating this sequence and we have done interoeprability
testing using this sequence.

> Common-sense would suggest that the ordering
> means something (generally we do step 1 before
> step 2), but there are some reasons for thinking
> that might not apply here.  :-)

I'd like to understand the reasons why you think it may 
not apply in this case.

> 
> First, there is no "then" or "else" prefixed to
> 2)...suggesting that the two sets of tests and
> actions are performed independently.

Well, none (or very few) of our numbered sequenced 
statemens start with "then"... so why would we do it
in this case?

> Second, as it
> turns out, however, the two sets of "if" conditions
> are not mutually exclusive and for certain values
> of the subject variables, performing 1) before 2)
> can lead to invalid, but unavoidable, results.
> (It's late here now, so I'm going to skip laying
> out a detailed example...but if anyone thinks it's
> necessary, I'll add it in a follow-up.)
> 
Pls post an example where you think we come to 
invalid results. I am not saying this is not true, 
but I believe we have gone through this a number of 
times in the past, and I think we came to the 
conclusion that this is what needs to be done.
We still may have overlooked a specific case, so
I'd love to hear it.


> The bottom line is that I think the tests and
> actions described in 2) need to be performed
> before those in 1) and that this ordering and
> the specific dependency need to be spelled out
> in any future revision of the spec.  That is,
> the time window check should be done before
> checks that might lead to updating the local
> record of the authEngine's timeliness variables.
> Doing them in reverse order (i.e., as currently
> ordered in the spec) can lead to situations in
> which otherwise out of time window messages
> morph into valid messages or, at the very least,
> inappropriately lead to "updates" of the local
> record of the authEngine's timeliness variables.
> 
Pls do realize, that at this point (3.2.7b) we are
dealing with an authenticated message. So this MUST 
be the real value that the AUTHORITATIVE engine
tells us about, no? So what is wrong with using that
value to update our local notion at the 
non-AUTHORITATIVE side of the communication?

Bert
> I will appreciate any and all feedback on this
> topic.
> 
> Cheers,
> 
> BobN
>