Re: GIST Q/D-mode issue

Hi all,

I also tend to like the "Option 1: Q-flag". It is a rather simple, yet 
clear, way to solve the problem. I don't see that using one more bit from 
the GHC is really that problematic.

Jukka

On Wed, 10 Sep 2008, Hancock, Robert wrote:

> hi all,
> 
> first, a couple of general points:
> 
> - 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].
> 
> 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.
> 
> - 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.)
> 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.
> 
> after that rather long digression, some more detailed points
> below:
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] On 
> > Behalf Of Roland Bless
> > Sent: 10 September 2008 12:15
> > To: Lauri J T Liuhto
> > Cc: [email protected]
> > Subject: Re: [NSIS] GIST Q/D-mode issue
> > 
> > Hi Lauri,
> > 
> > good that you are coming back on this issue, since I was also
> > a little bit confused by the proposal to use a new port for the
> > issue.
> > 
> > Lauri J T Liuhto wrote:
> > >  First a very short summary of the Q/D-mode issue of NTLPv16 Nuutti
> > >  Varis found in July:
> > > 
> > >         It seems that it is impossible to differentiate Q-mode and
> > >         D-mode Data messages in a middlebox if Data message is sent
> > >         with GIST Common Header S-flag set.
> > >  
> > >  A more detailed example of this issue is attached to the 
> > end of this
> > >  message.
> > > 
> > >  The issue was briefly discussed at Dublin, and it seems 
> > that we have
> > >  at least two different solutions to the issue:
> > > 
> > >  1) Add a "Q" flag to the GIST Common Header, that would be set
> > >     whenever the message is a Q-mode message.
> > >     + Closely resembles RAO in UDP payload
> yep
> > >     + Should be easy to fit in the spec
> yep
> >       + does not use another different well-known port number
> yes-ish (see below)
> > >     - Existing implementations need changes
> yep
> > >     - If done, only four free bits remain in GCH
> true (not a huge problem, but see anyway below).
> 
> > 
> > >  2) Use different port for D-mode messages.
> > >     + Scarce GCH flag reserve not used
> true
> > >     - Bigger changes to spec
> yes - in particular, is it a fixed or negotiated port
> > >     - Possible NAT/Firewall issues
> yes in either case (bigger issues if negotiated)
> > >     - Existing implementations need more complex changes
> yes
> >       - requires using a different well-known port number
> it doesn't necessary need to be well-known, just registered
> with IANA. (it could even be dynamic if the port is
> advertised by the receiver, but that is also more complicated.)
> > 
> > As an implementer I'm much in favor of solution 1):
> > requires only a few code changes and produces less error
> > cases, since in the using a different port case other
> > messages may arrive on the new port as well etc.
> > Listening on two different ports simultaneously for messages
> > also requires more system resources and probably major code changes
> > compared to 1).
> > 
> > I'd like to propose a different option 3): why not use a new message
> > type for stateless DATA messages? From the internal protocol logic
> > this would also be easy to implement as a Q-flag, since this type
> > of DATA message needs a special handling, but it avoids
> > wasting the flag bit.
> 
> 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. 
> 
> 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.)
> 
> 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.
> 
> robert h.
> 
> > 
> > Regards,
> >  Roland
> > _______________________________________________
> > nsis mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/nsis
> > 
> _______________________________________________
> nsis mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nsis
>