updated section references to relate to v12

The short summary: it is not possible to directly determine from the message
whether it is sent in Q-mode or not, since RAO checking might not work in end
system implementations (depending on limitations of the host stack) and port
number analysis might be invalidated by NATs. So it seems necessary to put the
magic number in all D mode packets.

Follow up discussion on the mailing list attached:

hi (to myself and others),

we had a few conversations about this in Prague. I'm reluctantly starting to
think that it might be better to use the magic number on all D-mode messages.

the main issue is NAT handling. in a NAT-free world, I still find it reasonable
to treat the GIST port specially (I think in our implementation it already has
to be treated specially for some RAO-related reasons, but don't quote me on that
...).

however, i know that some people use the GIST port as the source for Queries.
(you already have to use it as the source for Responses.) if you source Queries
from the GIST port and you are behind a NAT, then the Responder will not know
that what it sends back is going to go to the GIST port and so would not insert
the magic number.

we could partly address this by being more prescriptive about what ports get
used when, but this seems to be adding rather than removing complexity, and I
expect there would still be cases where port re-writing could get us into
trouble. OTOH, the fact that the encapsulation is UDP is pretty well invariant.

for the case where an end system receives a GIST message without the magic
number, I am still unclear on whether to generate an error or silently discard.

robert h.

> -----Original Message-----
> From: Hancock, Robert [mailto:robert.hancock@roke.co.uk]
> Sent: 14 March 2007 16:02
> To: Roland Bless
> Cc: nsis@ietf.org
> Subject: RE: [NSIS] GIST Q-Mode Encapsulation Magic Number
> 
> hi all,
> 
> > -----Original Message-----
> > From: Roland Bless [mailto:bless@tm.uka.de]
> > Sent: 14 March 2007 14:13
> > To: Hancock, Robert
> > Cc: Christian Dickmann; nsis@ietf.org
> > Subject: Re: [NSIS] GIST Q-Mode Encapsulation Magic Number
> > 
> > Hi Robert,
> > 
> > Hancock, Robert wrote:
> > > i think it is really a conceptual thing: i see the magic
> number as
> > > part of the encapsulation, just like the RAO and the UDP
> header and
> > > port number, since that is the purpose it serves (to demultiplex 
> > > packets, not to carry information). and to put it in
> every message
> > > would indeed be a waste of bytes, which you could never
> go back on
> > > (since the magic number comes before any version information).
> > > 
> > > another way of putting it: we want the magic number to be
> something
> > > that is checked to find out whether something is a GIST
> > packet, rather
> > > than part of parsing the GIST packet. making it part of
> the common
> > > header would blur that distinction.
> > 
> > I would agree on that. I see it as part of the encapsulation, too.
> > 
> > > however, it may be that in practice, what you suggest would be 
> > > simpler. i would be interested to hear what other people
> > think about
> > > that.
> > 
> > Hmm. I don't like the idea of carrying around that magic number 
> > always...
> > 
> > > one specific point: we need to ensure that GIST packets
> without the
> > > magic number go to a different UDP port, else you could not
> > know how
> > > to receive them properly. that may not be clear enough in
> > the spec at
> > > the moment.
> > 
> > That seems to be important and the devil lies in the details...
> > For example: Our implementation currently uses the
> well-known port as
> > source port for Q-mode packets since it is listening there anyways.
> > However, I assume that responses will not carry a magic number and 
> > thus we must change the Q-mode source port to something different...
> 
> i think this is one thing where we may need to update the current 
> specification text. if the confirm goes back in D-mode, there is no 
> mechanism in the protocol to indicate a port to send it to other than 
> the GIST port; so, in other words, we really should say that the magic 
> number is required for packets to the GIST port. (note that all Q-mode 
> packets go to the GIST port, but not vice versa.)
> 
> the other point is that you could receive a packet at the GIST port 
> with the incorrect magic number. At a router, this would be an 
> indication that this was not a GIST packet (and it would just get 
> forwarded); but at a host, it is a malformed packet. do we need an 
> error message for that? or should we silently discard it?
> 
> robert h.
> 
> > 
> > Regards,
> >  Roland
> > 
> 
> _______________________________________________
> nsis mailing list
> nsis@ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
nsis@ietf.org
https://www1.ietf.org/mailman/listinfo/nsis

reassign to v12 for corrections on magic number aspects

Added a new section 3.5 covering precisely this topic, pointing to more detailed
interception rules in 4.3.1 and encapsulation rules in 5.3.2. In particular,
added  a magic number to the Q-mode encapsulation in Section 5.3.2 to minimise
the risk of incorrect interception of UDP datagrams as GIST packets.

See http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue184 for the
revised encapsulation text including the magic number (overlapping issue).

New section 3.5:

3.5.  Effect on Internet Transparency

   GIST relies on routers inside the network to intercept and process
   packets which would normally be transmitted end-to-end.  This
   processing may be non-transparent: messages may be forwarded with
   modifications, or not forwarded at all.  This interception applies
   only to the encapsulation used for messages which initially probe the
   network, for example along a flow path; all other GIST messages are
   handled only by the nodes to which they are directly addressed, i.e.
   as normal Internet traffic.

   Because this interception potentially breaks Internet transparency
   for packets which are nothing to do with GIST, the encapsulation used
   by GIST in this case (called Query-mode or Q-mode) has several
   features to avoid accidental collisions with other traffic:

   o  Q-mode messages are always sent as UDP traffic, and to a specific
      well-known port allocated by IANA.

   o  The first 32-bit word of the UDP datagram payload contains a magic
      number.

   Even if a node intercepts a packet as potentially a GIST message,
   unless it passes both these checks it will be ignored at the GIST
   level and forward transparently.  Further discussion of the reception
   process is in Section 4.3.1 and the encapsulation in Section 5.3.2.

From Sam Hartman:

A section of the GIST document be added clearly indicating when a GIST
implementation can modify a packet not targeted for itself and when it is
expected to intercept such packets.  That is currently scattered too much
throughout the document.  Specific care should be given to cases where a GIST
node will not forward traffic for which it would normally act as a router.  In
particular, I think it would be harmful if traffic that happened to be on the
GIST UDP port were discarded if it clearly had no relation to GIST.