Subject: [NSIS] GIST Confirm contains no stack configuration data, which holds MA_HOLD_TIME

From: Thomas Herzog <[email-masked]>
Date: Tue, 25 Oct 2005 14:12:12 +0200

[sorry, I sent the last message as a reply, so some may have missed that this 
is a new issue if they use a threaded view in their mailer]

Hi all,

I am currently implementing a GIST instance, which can be configured to use 
Late State installation as described in Section 4.4.1.

Section 4.4.1 states, "the GIST-confirm must contain sufficient information to 
allow it to be processed identically to the original Query".

However, a GIST-Confirm does NOT contain a stack configuration data object (it 
is furthermore said, that even the stack proposal object it carries is a 
mirror of the one it received in the response).

When the Querier Node wants to set up a C-Mode Message Association, it will 
send the Confirm via the newly created C-Mode connection.

The Responder now must install the MA_HOLD_TIME of the Querier, so its MA 
State Machine can set the SendHello timer accordingly (GIST Hellos are sent 
from either direction to hold the MA open).

Unfortunately, in the late state installation case, it has no access to the 
Querier's MA_HOLD_TIME, as this would be carried in the stack configuration 
object, which is not included. (and even if it would be included, it should 
be the mirrored one from the Response, fitting to the stack proposal 
object...)

So in my eyes, with the current draft, there is no possibility to set up a 
Message Association in Late State Installation case!

Can someone elaborate on this and tell me if I am totally mistaken?

Cheers,
Thomas

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Roland Bless <[email-masked]>
Date: Tue, 25 Oct 2005 15:29:09 +0200

Hi Thomas,

> allow it to be processed identically to the original Query".

following from the problem below, the GIST-Confirm must contain at least
the MA-Hold-Time of the Q-Node. Sending the selected Q-Node Stack
Proposal in the  GIST-Confirm may be one viable option though this is
not really required since the MA was setup by the Q-Node already.

A further clarification may be required for the case when a Q-Node
sets up an MA that differs from the R-Node Stack Proposal, e.g.
the latter was TLS/TCP and TLS/SCTP :-), but the Q-Node setup a
normal TCP connection w/o TLS (to which the R-Node listens, too, for
connections of other peers). In this case the R-Node should check
that the Q-Node used an MA that is not allowed by the R-Node Stack
Proposal.

> from either direction to hold the MA open).

There should be another clarification in the draft.
When should a node send these GIST-MA-Hellos exactly? It is only
specified that
a node MUST not tear down state for the period of MA-Hold-Time if no
GIST message was seen over the MA. But I guess that setting the timer
near MA-Hold-Time may be to fragile and a static setting may possibly
cause undesired synchronization effects? Should the Hello send in the
interval somewhere between 0.7 and 0.95 * MA-Hold-Time to avoid
a tear down? Or should one set the NoActivity to MA-Hold-Time * 1.5?
While it is ok to leave some implementation freedom I guess that sending
a GIST-MA-Hello exactly every MA-Hold-Time msec will not work for all
implementations and scenarios.

> Message Association in Late State Installation case!

I assume you're correct here. Other experiences?

Regards,
 Roland