Re: GIST Q/D-mode issue

Dear all,

I'd like people to comment on this thread. This question is the last one 
before getting GIST accepted.

The proposal seems to be the addition of a Q-flag.

If people are fine with this, a short on the note list would be 
appreciated.

Jukka


On Wed, 17 Sep 2008, Robert Hancock wrote:

> hi,
> 
> comments below (mainly at the end). 
> 
> short summary: my preference at the moment is to
> use the flag bit method, but to put the flag at
> the start of the message type field. (saves a bit,
> and brings out the relationship between flag and
> message type.)
> 
> more below ... 
> 
> > -----Original Message-----
> > From: Roland Bless [mailto:[email protected]] 
> > Sent: 11 September 2008 08:38
> > To: Hancock, Robert
> > Cc: Lauri J T Liuhto; [email protected]
> > Subject: Re: [NSIS] GIST Q/D-mode issue
> > 
> > Hi Robert,
> > 
> > thanks for elaborating this. Some more comments below.
> > 
> > Hancock, Robert wrote:
> > > - at the conceptual level, i think we should distinguish 
> > > between (a) whether a message is sent in Q- or D-mode, and
> > > (b) whether a message has to be interpreted when received 
> > > in the absence of routing state. in the current spec, either
> > > of these classify messages the same way, but the concepts 
> > > are distinct: (a) is about sender behaviour [mainly, formatting
> > > the message to follow a data path] and (b) is about
> > > receiver behaviour [knowing how to decode what you get].
> > 
> > That's exactly true, nice and clear distinction that I had
> > in mind, but I wasn't able to express it so clearly :-)
> > For Q-mode Data messages the concepts were a little bit
> > intermingled since a Data message had to be interpreted differently
> > if received in Q-mode (as you describe below, too).
> > 
> > > The overall issue comes up in the NAT traversal case, and
> > > the point (I think) is that the NAT has to do special 
> > > special processing for messages received without prior
> > > routing state.
> > 
> > Ok.
> > 
> > > - this actually exposes a flaw in the previous spec: it was
> > > never supposed to matter to a receiver whether a message
> > > was received in Q- or D-mode, it only mattered to the
> > > sender. (The receiver only cared about the message type.)
> > 
> > > The fact that it was possible to tell the difference from
> > > the presence of the RAO was a design artifact (the RAO was
> > > supposed to assist message interception, not change the
> > > semantics of the message.)
> > 
> > Yes, however, if a message came with an RAO, it came via Q-mode
> > encapsulation and that was what mattered for our case distinction.
> 
> that's quite right - my point was that you should not have had
> to use the RAO to work that out.
> 
> > 
> > > Taking into account the conceptual distinctions above, it
> > > is still the case that it shouldn't matter to the 
> > > receiver whether a message was in Q- or D-mode, but it does
> > > matter whether routing state is supposed to be used in
> > > interpreting it.
> > 
> > If I look at our source code we first check whether
> > a corresponding routing state exists and then check
> > for the message type. If the Data message came via Q-mode,
> > we deliver it, if it did not arrive via Q-mode
> > we have an error condition (e.g, because a Confirm
> > was lost):
> > https://projekte.tm.uni-karlsruhe.de/trac/NSIS/browser/ntlp/tr
> unk/src/ntlp_statemodule_main.cpp#L703
> > So Q-mode/D-mode distinction is in this case important
> > to decide whether the Data message has to be interpreted although
> > no routing state exists. That could also be achieved by the
> > different message type that I proposed, but I agree with your
> > counter argument below.
> > 
> > > this is half attractive for saving the flag bit. however, there is
> > > an issue about extensibility: what if later on another message type
> > > turns up which also needs to be processed by the NAT in the same
> > > way - the NAT implementations need to have a list of message
> > > types to care about, and that list might extend. 
> > 
> > Ok, good point. In that case it is a good reason to do it differently.
> > 
> > > but there's another way of saying the same thing: divide the message
> > > types into two classes, those to be intercepted by NATs and those
> > > which are not. distinguish them by the high-bit in the message 
> > > type field. (it reduces the number of distinct message types from
> > > 256 to 128, but that seems not impossible.) obviously, this is the
> > > same as just putting the hypothetical Q-flag in a different place
> > > in the header (and calling it something else.)
> > 
> > Yep. I think it is useful to have an explicit indication for
> > your function (a), i.e., a Q-mode flag in the message, however,
> > formerly whether a GIST message arrived via Q-mode or D-mode
> > was not visible in the GIST message itself, only by the outer
> > encapsulation method. Having a Q-mode flag would now generate
> > new error conditions to check for, e.g, if Q-mode flag is set
> > in a C-mode message etc.
> 
> indeed (see also at the end). i think we would have one extra
> error, 'invalid Q-flag' causing the message to be dropped.
> (I see it as another instance of a formatting error.)
> 
> > 
> > > in another mail:
> > > 
> > >> Max Laier proposed option 4):
> > >> use a different magic number for Q-Mode and D-Mode messages.
> > >> Any opinions?
> > > 
> > > i don't really like this. i have generated the appropriate
> > > random number (4d62 8fa0), but it still seems like a hack.
> > > and the same issues about extensibility apply.
> > > 
> > > when i first analysed this problem, i couldn't find a better
> > > solution than the Q-flag or something like it: in other words,
> > > you have to change the message formats. within the design
> > > space of format changes, my favourite is still option (1), or
> > > modified option (3) if flag bit space exhaustion seems like
> > > a problem.
> > 
> > Agreed. The question is, whether there are cases in which
> > the message does not arrive via Q-mode, but the message has
> > to be interpreted nevertheless in case of missing routing state.
> > So this would be a flag exactly for your function (b) from above,
> > something like a stateLess flag
> > "if this message arrived and no routing state exists,
> > it is ok to interpret it nevertheless". However, since this is
> > allowed for certain message types only we have to check the
> > particular message type, too. So it is not clear to me, whether
> > we could actually avoid the above mentioned list of message types
> > that NATs have to care about.
> 
> there are two points:
> 
> - for a NAT, it does the operation on the message based on the
> presence of the Q flag only. it doesn't check if that flag was
> valid for the message type.
> 
> - the end system needs to decide if the Q flag, message type, and
> internal state are all consistent. this will require logic changes
> if the set of message types changes - but these would be required
> at the end system anyway (to cope with a new message).
> 
> cheers,
> 
> robert h.
> 
> > 
> > Regards,
> >  Roland
> > 
> > 
> 
> _______________________________________________
> nsis mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nsis
>