Subject: [NSIS] GIST issue on forwarders introducing errors

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 12 Oct 2006 11:26:10 +0100

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.

b) allow or force the forwarding node to introduce a new object to
indicate that it has processed the message in some non-trivial way
(effectively introducing route recording). Probably one would still want
to report errors to the originator, but the error reporter would also
include the recorded route to make diagnostics easier. Disadvantage of
this approach: it makes the implementation of forwarding more complex,
and in particular rules out implementations which do simple in-place
modifications of the message (the goal for RMD for example).

c) allow the originating node to include an object which records the
route taken through any forwarding nodes. this object would be of
extensibility class AB=10 (forward unchanged) or possibly AB=00 (reject
if unknown). Typically, the
originating node would only include such an object for diagnostic
purposes (to
avoid putting additional processing load on the forwarders).

c') same as (c), but define the object as part of the base specification
(so all nodes would support it from the start).

d) depend on a future GIST traceroute capability (e.g. the NSIS ping
approach)
to discover such forwarding nodes and find out what they are doing. So,
the
diagnostics would not be built into the base protocol, but would be
available as an extension to support investigations if message mangling
by forwarders turns out to be a problem.

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

---

From: Ruud Klaver <[email-masked]>
Date: Thu, 12 Oct 2006 15:52:52 +0200

Hi Robert,

 

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

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 19 Oct 2006 16:04:04 +0200

Hi Robert,

My preference is a). Taking care for all sources of implementation  
errors is IMHO just impossible.

   Martin

Am 12.10.2006 um 12:26 schrieb Hancock, Robert:

> c) allow tFrom [email-masked] Thu Oct 19 11:11:39 2006
From: Martin Stiemerling <[email-masked]>
Subject: Re: [NSIS] messages content
Date: Thu, 19 Oct 2006 16:11:29 +0200
To: "Lars Westberg (KI/EAB)" <[email-masked]>
Cc: nsis <[email-masked]>

(NSIS co-chair hat off -- implementors hat on)

I have been also implementing the NTLP and it took me 2 weeks to get  
a basic version up and running. This version has been tested at the  
Paris interop event in Summer 2005.

So my from point of view as an implementor I couldn't say which part  
of the NTLP draft is unclear or not easy to be implemented. It is an  
excellent protocol specification!

   Martin

Am 17.10.2006 um 16:50 schrieb Christian Dickmann:

> Hi,
>
> I am the main developer of the GIST implementation of the  
> University of Goettingen.
> To me, the draft explains how messages look like pretty well and I  
> have no clue how
> the draft could be more precise (from the structure point of view).
>
>> I can't all questions on the list.  I would rather appreciate an  
>> example
>> implementation of it with message shown in text-format. Does the
>> implementation showing the messages in text ??
>>
>> If so, I am interested in it. Is it possible to get a copy ???
>>
>
> We implemented an dissector, which is able to display GIST (and  
> QoS, NATFW, etc.)
> messages in the popular network protocol analyzer Ethereal (now  
> known as Wireshark).
> In addition, we got several captures of NSIS sessions (some of them  
> captured at the
> recent Interop event) that we can provide.
> So with this, you can look at every message, look at every detail  
> you want and see how
> GIST works in real life.
>
> Please have a look at http://user.informatik.uni-goettingen.de/ 
> ~nsis/ethereal.html
>
> Christian Dickmann
>
>