Subject: [NSIS] GIST Draft-14 Refresh/Confirm

From: Roland Bless <[email-masked]>
Date: Tue, 31 Jul 2007 11:43:15 +0200

Hi Robert,

during the revision of our code I came across the
following issue:
for the following cases I assume that an initial
handshake for C-mode already happened and that
an MA has been properly setup. While it is really
clearly described what to do for C-Mode/MA setup it is
less clear for routing state refreshes.

- Is it necessary for a _refreshing_ Query to contain
  a stack proposal in order to indicate C-mode usage?

- Is it possible that a refresh for C-mode uses only
  Query and a Response in D-mode? I would say no from
  the table in sec. 5.5, but I could not find it anywhere
  in the text. Sec. 5.1 says it MAY be sent in C-mode
  if an existing MA is being re-used, whereas I interpret
  the table from sec. 5.5 that this is actually a MUST, i.e.
  it MUST be sent in C-mode in case an existing is being
  re-used. This also matches the text from sec. 4.4.3:

      Section 5.7.1.  This is indicated by sending the remaining
      messages in the handshake over that association.  This will lead

  So I guess a refresh for C-mode consists at least of
  a Query and a Response sent back in C-Mode.

- I was not absolutely sure about how to send the Confirm that
  may be used in case of a state refresh, because most of the
  text seems to be related to state setup but not to a refresh.
  Though now it is really clear that a confirm is always required
  for initial C-mode setup and otherwise it is only required
  if a Response requests it. The only hints that I found are:
  * Sec. 5.1: A Confirm MUST be sent in C-mode if a messaging
   association is being used for this routing state, and MUST be
   sent before other messages for this routing state.
  [while the first part is pretty clear, the second part sounds
  as it would be related to an MA setup only]
  * Table in 5.5 says Confirm C-Mode usage: if an MA has been set up
  or is being re-used and the column for D-Mode is the logical
  negation of this, so D-Mode is not allowed.
  Explicitly saying that Response/Confirm must be sent in C-Mode
  for an existing usable MA would be nice.

- Section 5.5 now mentions that if the Confirm didn't
  arrive via the C-Mode that an Incorrect Encapsulation
  Error should be sent. It would be good to mention this
  in A.4.4.3, too.

Sorry for being nitpicking,
 Roland

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