Subject: RE: [NSIS] GIST issue on forwarders introducing errors

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 12 Oct 2006 15:05:28 +0100

Hi Ruud,

to be clear (it may be clearer from the full text in the issue 
tracker), the point we are talking about here is how to handle
the case of implementation errors in the forwarding node. A
correctly implemented forwarder would never cause this problem.
However (as Adrian pointed out), a correctly implemented 
originating node would never generate erroneous messages either,
but we still have the error messages to report about them when
they do. So, the question is, can we make ourselves sufficiently
confident that this (forwarders mangling messages) is a class 
of implementation error that we do not have to deal with.

hope this helps,

r.

> -----Original Message-----
> From: Ruud Klaver [mailto:[email-masked]] 
> Sent: 12 October 2006 14:53
> To: [email-masked]
> Subject: Re: [NSIS] GIST issue on forwarders introducing errors
> 
> 
> Hi Robert,
> 
> Thursday, October 12, 2006, 12:26:10, you wrote:
> 
> > Hi all,
> 
> > An issue has been raised on GIST nodes that process and forward 
> > messages introducing errors, and how to diagnose such 
> errors. It is in 
> > the tracker as issue #132
> > 
> (http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue132)
> > and the summary text
> > is included below.
>  
> > This is a solicitation for input, especially from the
> > implementors, on this matter. In the absence of input, my 
> > preference would be to leave the current protocol unchanged,
> > but put stronger guidance in about it - this is essentially
> > (a) below, pointing to (c) or (d) as possible future extensions.
> > Or, we could extend the current specification along the lines of
> > (b) or (c'). Please provide your preferences!
> 
> > cheers,
> 
> > robert h.
> 
> > ==============================================================
> > [Following Routing Area Directorate comments from Adrian Farrel]
> 
> > The GIST specification allows nodes to forward messages, 
> either after 
> > consultation  with the NSLP (section 4.3.2) or if there is no local 
> > NSLP (4.3.4). However, the forwarding process does not 
> change the IP 
> > header or included Network-Layer-Information object. This 
> means that 
> > any errors introduced by the forwarding node will get 
> reported back to 
> > the node that first originated the message; this will get confused 
> > because it is being told about error conditions which it was not 
> > responsible for.
> 
> > There are several possible approaches for dealing with this:
> 
> > a) note more strongly in the text that the forwarder is 
> supposed not 
> > to change any of the GIST payloads, so it should not introduce any 
> > errors. Disadvantage of this: we have to trust 
> implementations which 
> > do forwarding to be correctly
> > written so that they do not introduce message changes in 
> the process.
> 
> I would think it to be quite obvious from the text right now 
> that only the NSLP payload can be changed when forwarding 
> messages, at least that's the only thing my implementation 
> allows right now.
> 
> Could you give a practical example of a node changing part of 
> the GIST payload of forwarded message? Is there any 
> non-malicious point to this?
> 
> -- 
> Best regards,
>  Ruud Klaver                     mailto:[email-masked]
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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