Subject: [NSIS] GIST Q-Mode Encapsulation Magic Number

From: Christian Dickmann <[email-masked]>
Date: Fri, 09 Mar 2007 12:42:02 -0500

Hi,

I just read the new GIST draft version (-12) with respect to the new 
magic number which is sent in front of the Q-Mode packets.
 From my point of view, the magic number definition is quite well hidden 
in Section 5.3.2.3. I thought it should be part of the Bit-Level Format 
Appendix, as it is part of how a GIST packet looks like. In addition, 
Section 5.1 does not indicate at all, that there is something in front 
of a GIST packet.
Maybe thats a stupid idea, but from an implementors point of view it 
would be much easier to make the magic number part of the Common Header. 
This way, it is always included (OK, waste of 4 bytes in non-Queries) 
which makes it more obvious w.r.t. the specification and makes 
implementation easier as well.
Is there any reason besides wasting 4 bytes for non-Queries to NOT make 
it part of the Common Header?

Regards,
Christian Dickmann

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 12 Mar 2007 13:53:38 -0000

hi christian,

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.

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.

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.

cheers,

robert h.

> -----Original Message-----
> From: Christian Dickmann [mailto:[email-masked]] 
> Sent: 09 March 2007 17:42
> To: [email-masked]
> Subject: [NSIS] GIST Q-Mode Encapsulation Magic Number
> 
> Hi,
> 
> I just read the new GIST draft version (-12) with respect to 
> the new magic number which is sent in front of the Q-Mode packets.
>  From my point of view, the magic number definition is quite 
> well hidden in Section 5.3.2.3. I thought it should be part 
> of the Bit-Level Format Appendix, as it is part of how a GIST 
> packet looks like. In addition, Section 5.1 does not indicate 
> at all, that there is something in front of a GIST packet.
> Maybe thats a stupid idea, but from an implementors point of 
> view it would be much easier to make the magic number part of 
> the Common Header. 
> This way, it is always included (OK, waste of 4 bytes in 
> non-Queries) which makes it more obvious w.r.t. the 
> specification and makes implementation easier as well.
> Is there any reason besides wasting 4 bytes for non-Queries 
> to NOT make it part of the Common Header?
> 
> Regards,
> Christian Dickmann
> 
>

---

From: Christian Dickmann <[email-masked]>
Date: Mon, 12 Mar 2007 10:43:26 -0400

Hi Robert,

> in the spec at the moment.

The last point came to my mind as well. If the magic number stays being 
part of Q-Mode only, the spec should be very clear about the fact, that 
you should not use the same port for normal encapsulation, which again 
makes implementation not easier ...

Christian Dickmann

---

From: Roland Bless <[email-masked]>
Date: Wed, 14 Mar 2007 15:12:55 +0100

Hi Robert,

> the common header would blur that distinction.

I would agree on that. I see it as part of the encapsulation, too.

> simpler. i would be interested to hear what other people think

Hmm. I don't like the idea of carrying around that magic number
always...

> 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...

Regards,
 Roland

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 14 Mar 2007 16:02:01 -0000

hi all, 

> From: Roland Bless [mailto:[email-masked]] 
> Sent: 14 March 2007 14:13
> To: Hancock, Robert
> Cc: Christian Dickmann; [email-masked]
> 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).
> > 
> > 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.
> 
> > 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.
> 
> 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.

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 28 Mar 2007 15:19:14 +0100

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.

> From: Hancock, Robert [mailto:[email-masked]] 
> Sent: 14 March 2007 16:02
> To: Roland Bless
> Cc: [email-masked]
> Subject: RE: [NSIS] GIST Q-Mode Encapsulation Magic Number
> 
> hi all, 
> 
> 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
> > 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 29 Mar 2007 23:23:17 -0400

I'm all for consistency. Besides a few extra bits, is there any  
disadvantage in including the magic number?

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 30 Mar 2007 11:03:03 +0200

Hi Robert and all,

> RAO-related reasons, but don't quote me on that ...).

Putting the magic number always in would be consistent and GIST would  
be prepared for whatever it encounters en-route :-)

> to go to the GIST port and so would not insert the magic number.

It is always a bad idea to rely on a specific transport layer port,  
as for NATing reasons. GIST should allow to take any source port for  
Queries.

I know that some implementations didn't work properly when using a  
different source port as the standard source port for GIST. I.e.,  
these implementations were always replying to the standard GIST  
source port even though the actual source port was random.  
Apparently, this made some unnecessary troubles.

> encapsulation is UDP is pretty well invariant.

See above.

> error or silently discard.

IFrom [email-masked] Fri Mar 30 05:03:47 2007
From: Martin Stiemerling <[email-masked]>
Subject: Re: [NSIS] GIST Q-Mode Encapsulation Magic Number
Date: Fri, 30 Mar 2007 11:03:03 +0200
To: "Hancock, Robert" <[email-masked]>
Cc: [email-masked]

Hi Robert and all,

> RAO-related reasons, but don't quote me on that ...).

Putting the magic number always in would be consistent and GIST would  
be prepared for whatever it encounters en-route :-)

> to go to the GIST port and so would not insert the magic number.

It is always a bad idea to rely on a specific transport layer port,  
as for NATing reasons. GIST should allow to take any source port for  
Queries.

I know that some implementations didn't work properly when using a  
different source port as the standard source port for GIST. I.e.,  
these implementations were always replying to the standard GIST  
source port even though the actual source port was random.  
Apparently, this made some unnecessary troubles.

> encapsulation is UDP is pretty well invariant.

See above.

> error or silently discard.

I tend so say "send an error" message, given that the magic number  
MUST be present anyway.

   Martin

>> should we silently discard it?

[email-masked]
NEC Europe Limited |
Registered Office: NEC House, 1 Victoria Road, London W3 6BL |
Registered in England 2832014

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 30 Mar 2007 10:16:00 +0100

hi, 

> From: Henning Schulzrinne [mailto:[email-masked]] 
> Sent: 30 March 2007 04:23
> To: Hancock, Robert
> Cc: [email-masked]
> I'm all for consistency. Besides a few extra bits, is there 
> any disadvantage in including the magic number?

by now, it's just the bits.

conceptually, there is a big difference between Q- and 'normal' 
D-mode encapsulations. but the difference is only easy to detect
at the sender, and can be hard to detect at the receiver, 
especially when it is an endpoint. 

the Postel principle seems to apply here.

robert h.