Re: GIST Q/D-mode issue

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
>