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 |
