NSIS-ka
A free C++ implementation of NSIS protocols

Interop-20070509: draft-dickmann-nsis-ntlp-interop-00.txt

File draft-dickmann-nsis-ntlp-interop-00.txt, 54.8 KB (added by bless, 10 years ago)

draft-dickmann-nsis-ntlp-interop-00.txt

Line 
1
2
3
4Next Steps in Signaling                                      C. Dickmann
5Internet-Draft                                  University of Goettingen
6Expires: September 2, 2007                                    March 2007
7
8
9General Internet Signaling Transport (GIST) Interoperability Test Suite
10                  draft-dickmann-nsis-ntlp-interop-00
11
12Status of this Memo
13
14   By submitting this Internet-Draft, each author represents that any
15   applicable patent or other IPR claims of which he or she is aware
16   have been or will be disclosed, and any of which he or she becomes
17   aware will be disclosed, in accordance with Section 6 of BCP 79.
18
19   Internet-Drafts are working documents of the Internet Engineering
20   Task Force (IETF), its areas, and its working groups.  Note that
21   other groups may also distribute working documents as Internet-
22   Drafts.
23
24   Internet-Drafts are draft documents valid for a maximum of six months
25   and may be updated, replaced, or obsoleted by other documents at any
26   time.  It is inappropriate to use Internet-Drafts as reference
27   material or to cite them other than as "work in progress."
28
29   The list of current Internet-Drafts can be accessed at
30   http://www.ietf.org/ietf/1id-abstracts.txt.
31
32   The list of Internet-Draft Shadow Directories can be accessed at
33   http://www.ietf.org/shadow.html.
34
35   This Internet-Draft will expire on September 2, 2007.
36
37Copyright Notice
38
39   Copyright (C) The IETF Trust (2007).
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55Dickmann                Expires September 2, 2007               [Page 1]
56
57Internet-Draft      GIST Interoperability Test Suite          March 2007
58
59
60Abstract
61
62   This document describes a collection of test cases to be used for
63   interoperability testing of the General Internet Signalling Transport
64   (GIST) protocol.  Each test case consists of a description, the
65   expected behavior and a trigger.  The triggers are given using calls
66   to the Abstract GIST API defined in the GIST specification.
67
68
69Table of Contents
70
71   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
72   2.  Terminology and Abbreviations  . . . . . . . . . . . . . . . .  4
73   3.  GIST protocol test suite . . . . . . . . . . . . . . . . . . .  5
74     3.1.  Methodology  . . . . . . . . . . . . . . . . . . . . . . .  5
75       3.1.1.  Roles and network setup  . . . . . . . . . . . . . . .  5
76       3.1.2.  Structure of test cases  . . . . . . . . . . . . . . .  5
77       3.1.3.  GIST API Call Patterns . . . . . . . . . . . . . . . .  6
78     3.2.  Required Test Cases  . . . . . . . . . . . . . . . . . . .  8
79       3.2.1.  3-Way Handshake  . . . . . . . . . . . . . . . . . . .  8
80       3.2.2.  Refresh of soft state  . . . . . . . . . . . . . . . . 14
81       3.2.3.  Setup of multiple sessions . . . . . . . . . . . . . . 17
82       3.2.4.  Interception on NSIS forwarders  . . . . . . . . . . . 18
83       3.2.5.  GIST Stateless operation . . . . . . . . . . . . . . . 21
84       3.2.6.  Message composition  . . . . . . . . . . . . . . . . . 21
85       3.2.7.  Upstream Queries . . . . . . . . . . . . . . . . . . . 22
86       3.2.8.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . 22
87     3.3.  Additional . . . . . . . . . . . . . . . . . . . . . . . . 23
88       3.3.1.  GIST transport protocols . . . . . . . . . . . . . . . 23
89   4.  Definition of Interop/Testing NSLP . . . . . . . . . . . . . . 24
90     4.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . 24
91   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
92   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 26
93   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 27
94   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
95     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 28
96     8.2.  Informative References . . . . . . . . . . . . . . . . . . 28
97   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29
98   Intellectual Property and Copyright Statements . . . . . . . . . . 30
99
100
101
102
103
104
105
106
107
108
109
110
111Dickmann                Expires September 2, 2007               [Page 2]
112
113Internet-Draft      GIST Interoperability Test Suite          March 2007
114
115
1161.  Introduction
117
118   TODO
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167Dickmann                Expires September 2, 2007               [Page 3]
168
169Internet-Draft      GIST Interoperability Test Suite          March 2007
170
171
1722.  Terminology and Abbreviations
173
174   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
175   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
176   "OPTIONAL", in this document are to be interpreted as described in
177   BCP 14, RFC 2119 [2].
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223Dickmann                Expires September 2, 2007               [Page 4]
224
225Internet-Draft      GIST Interoperability Test Suite          March 2007
226
227
2283.  GIST protocol test suite
229
2303.1.  Methodology
231
2323.1.1.  Roles and network setup
233
234   Most test cases described in this document are based on a generic
235   network setup.  Nodes might take the following roles:
236   o  NSIS Initiator: This node initiates the test case and acts as the
237      Querying node according to the GIST specification.
238   o  NSIS Receiver: This node is the destination of the data flow that
239      is signaled for.  It might act as the Responding node.
240   o  NSIS Forwarder: This node is along the path the data flow takes
241      towards the destination.  It might act as the Responding node,
242      just by-pass GIST messages at the IP or GIST layer or it might
243      even be not present at all.
244   o  Non-NSIS Forwarder: This node is used as an on-path packet
245      modifier/dropper.  It can be placed between NSIS Initiator and
246      NSIS Forwarder/Receiver to simulate error conditions, like packet
247      loss, on-path attackers or broken implementations.  In some test
248      cases, it must not be present.
249
250   Figure 1 depicts how these nodes need to be interconnected to perform
251   the test cases described in this document.
252
253   +---------+       +---------+       +---------+       +---------+
254   |  NSIS   |       |Non-NSIS |       |  NSIS   |       |  NSIS   |
255   |Initiator|<----->|Forwarder|<----->|Forwarder|<----->|Receiver |
256   +---------+       +---------+       +---------+       +---------+
257
258
259                                 Figure 1
260
261   It has to be noted that the roles given above are only logical
262   entities and multiple roles MAY be combined into one physical node.
263   For example, NSIS Forwarder and NSIS Receiver MAY be represented by
264   the same physical node.  However, the testing parties have to make
265   sure, that neither expected behavior nor triggers are effected by
266   this decision.
267
2683.1.2.  Structure of test cases
269
270   The test cases in this document test the interoperability of two GIST
271   implementations (called vendors throughout the remainder of this
272   document).  One vendor takes the role of NSIS Initiator, while the
273   other one is either NSIS Forwarder or NSIS Receiver.  If not
274   otherwise noted, the test cases are described from the perspective of
275   the NSIS Initiator.  Also if not otherwise noted, all test cases MUST
276
277
278
279Dickmann                Expires September 2, 2007               [Page 5]
280
281Internet-Draft      GIST Interoperability Test Suite          March 2007
282
283
284   be performed with switched roles to confirm interoperability.
285
286   All test cases use the following structure.  First, a general
287   description is given, highlighting the scenario and the expected
288   result.  The expected behavior is then explained in more detail.  In
289   addition, each test case provides information on how it can be
290   triggered.  These triggers include, but are not limited to:
291   o  Which action the test initiator should perform.  This action is
292      expressed in terms of calls to the Abstract GIST API given in [1].
293      To avoid repeating all details, call patterns are defined below
294      which are then referenced by the test cases.
295   o  The actions the Non-NSIS Forwarder should perform, like dropping
296      GIST packets or modifying fields of GIST objects.  Tests related
297      to normal operation will usually not specify any action for the
298      Non-NSIS Forwarder, which means that it is supposed to act as a
299      normal IP router.  Some tests might even require the Non-NSIS
300      Forwarder to be not present at all.
301   o  The role the other vendor should take in this test case.  This
302      will be either forwarder or receiver.
303   Finally, test cases might contain notes that help to perform the test
304   or describe common problems.
305
306   All states of both vendors MUST be cleared between tests (e.g. by
307   restarting the implementations).  The order in which the test cases
308   are given in this document MUST NOT affect the outcome of the tests.
309   Instead, the order chosen in this document is just an aid.  It
310   separates functional groups of GIST operation, as well as normal
311   operation from recoverable and unrecoverable protocol situations and
312   thus helping isolating and correcting bugs or specification
313   violations most efficiently.
314
3153.1.3.  GIST API Call Patterns
316
317   This section defines several call patterns to GIST API primitives.
318   The relavent primitives given by [1] are as follows:
319
320   SendMessage ( NSLP-Data, NSLP-Data-Size, NSLP-Message-Handle,
321                 NSLP-Id, Session-ID, MRI,
322                 SSI-Handle, Transfer-Attributes, Timeout, IP-TTL, GHC )
323
324
325
326   SetStateLifetime ( NSLPID, MRI, State-Lifetime )
327
328
329   This document defines the following call patterns:
330
331
332
333
334
335Dickmann                Expires September 2, 2007               [Page 6]
336
337Internet-Draft      GIST Interoperability Test Suite          March 2007
338
339
340   o  Call A: Send message in unreliable D-Mode:
341      SendMessage(<Data>, <DataSize>, <MessageHandle>, NSLPID =
342      InteropNSLPID, SID = 1, <MRI>, NULL, Transfer-Attributes =
343      (Reliability = unreliable, Security = insecure, SetupRoutingState
344      = yes), Timeout = 10 seconds, IP-TTL = 50, GIST-Hop-Count = 50);
345   o  Call B: Send message in reliable, but potentially insecure C-Mode:
346      SendMessage(<Data>, <DataSize>, <MessageHandle>, NSLPID =
347      InteropNSLPID, SID = 1, <MRI>, NULL, Transfer-Attributes =
348      (Reliability = reliable, Security = insecure, SetupRoutingState =
349      yes), Timeout = 10 seconds, IP-TTL = 50, GIST-Hop-Count = 50);
350   o  Call C: Send message in reliable and secure C-Mode:
351      SendMessage(<Data>, <DataSize>, <MessageHandle>, NSLPID =
352      InteropNSLPID, SID = 1, <MRI>, NULL, Transfer-Attributes =
353      (Reliability = reliable, Security = secure (TODO: should be more
354      precise, see API spec), SetupRoutingState = yes), Timeout = 10
355      seconds, IP-TTL = 50, GIST-Hop-Count = 50);
356   o  Call D: Send message in reliable, but potentially insecure C-Mode
357      and use secondary Session ID:
358      SendMessage(<Data>, <DataSize>, <MessageHandle>, NSLPID =
359      InteropNSLPID, SID = 2, <MRI>, NULL, Transfer-Attributes =
360      (Reliability = reliable, Security = insecure, SetupRoutingState =
361      yes), Timeout = 10 seconds, IP-TTL = 50, GIST-Hop-Count = 50);
362   o  Call E: Send message in reliable, but potentially insecure C-Mode
363      and use secondary NSLP ID:
364      SendMessage(<Data>, <DataSize>, <MessageHandle>, NSLPID =
365      InteropNSLPID2, SID = 1, <MRI>, NULL, Transfer-Attributes =
366      (Reliability = reliable, Security = insecure, SetupRoutingState =
367      yes), Timeout = 10 seconds, IP-TTL = 50, GIST-Hop-Count = 50);
368   o  Call F: Terminate primary session:
369      SetStateLifeTime(NSLPID = InteropNSLPID, <MRI>, SID = 1, State-
370      Lifetime = 0);
371   o  Call G: Send message in unreliable, insecure and stateless D-Mode:
372      SendMessage(<Data>, <DataSize>, <MessageHandle>, NSLPID =
373      InteropNSLPID, SID = 1, <MRI>, NULL, Transfer-Attributes =
374      (Reliability = unreliable, Security = insecure, SetupRoutingState
375      = no), Timeout = 10 seconds, IP-TTL = 50, GIST-Hop-Count = 50);
376   o  Call H: Send message in reliable and secure C-Mode and use
377      secondary Session ID:
378      SendMessage(<Data>, <DataSize>, <MessageHandle>, NSLPID =
379      InteropNSLPID, SID = 2, <MRI>, NULL, Transfer-Attributes =
380      (Reliability = reliable, Security = secure, SetupRoutingState =
381      yes), Timeout = 10 seconds, IP-TTL = 50, GIST-Hop-Count = 50);
382   o  Call J: Send message in unreliable D-Mode with a source address in
383      the MRI which places the local node on the IP path towards the
384      receiver:
385      SendMessage(<Data>, <DataSize>, <MessageHandle>, NSLPID =
386      InteropNSLPID, SID = 1, <MRI> = (Source Address != local node),
387      NULL, Transfer-Attributes = (Reliability = unreliable, Security =
388
389
390
391Dickmann                Expires September 2, 2007               [Page 7]
392
393Internet-Draft      GIST Interoperability Test Suite          March 2007
394
395
396      insecure, SetupRoutingState = yes), Timeout = 10 seconds, IP-TTL =
397      50, GIST-Hop-Count = 50);
398
399   The values for InteropNSLPID and InteropNSLPID2 should be chosen from
400   the Private/Experimental space defined by [1].  This document assumes
401   the values 32704 and 32705, respectivly.  The call patterns defined
402   above are assumed to be executed by a special Interop NSLP, which is
403   explained in more detail in Section 4.
404
405   Please note, that implementations MAY choose to not use the Interop
406   NSLP and/or the call patterns and triggers defined in this document.
407   For example, if an implementation provides a special debugging/
408   testing interface that can be used to trigger the test cases more
409   easily, this interface MAY be used instead of the Interop NSLP.
410   However, it must be made sure that there are no other side effects
411   which corrupt the test results.  Furthermore, interopability with
412   other implementations that choose to use the Interop NSLP needs to be
413   guaranteed.
414
4153.2.  Required Test Cases
416
4173.2.1.  3-Way Handshake
418
419   GIST implementations must be able to perform the 3-way handshake in
420   order to set up Message Routing State (MRS).  The Path-Coupled
421   Message Routing Method (PC-MRM) must be used and the Message Routing
422   Information (MRI) must use the Querying node's IP address as source
423   address and the Responding node's IP address as destination address.
424   The direction of the initial Query must be set to downstream.  A GIST
425   implementation MUST pass the following test cases for setup of MRS:
426
427   Tests related to normal operation:
428   o  Test: 1.1
429      Description:  Positive test for setup of MRS which does not relate
430         to setup of a Messaging Association (MA), i.e. the Query does
431         not contain a Stack-Proposal.
432      Expected behavior:  Message exchange must consist of Query,
433         Response and Confirm messages, all sent in D-Mode.
434      Trigger:  Initiator perform Call A. Run other vendor as NSIS
435         Receiver.
436      Note:  Local policy of the Querying node must not enforce C-Mode.
437
438   o  Test: 1.2
439      Description:  Positive test for setup of MRS which relates to
440         setup of an (potentially) insecure MA, i.e. the Query contains
441         a Stack-Proposal.
442
443
444
445
446
447Dickmann                Expires September 2, 2007               [Page 8]
448
449Internet-Draft      GIST Interoperability Test Suite          March 2007
450
451
452      Expected behavior:  Message exchange must consist of Query and
453         Response sent in D-Mode, establishment of the MA and the
454         Confirm sent over the newly created MA.
455      Trigger:  Initiator perform Call B. Run other vendor as NSIS
456         Receiver.
457      Note:  The exact stack of transport protocols used depends on the
458         Stack-Proposal negotiation and is subject to local policy.
459
460   o  Test: 1.3
461      Description:  Positive test for setup of MRS which relates to
462         setup of an MA, which allows the transport of secure messages.
463      Expected behavior:  Message exchange must consist of Query and
464         Response sent in D-Mode, establishment of the MA and the
465         Confirm sent over the newly created MA.  The Query must contain
466         a Stack-Proposal which does not propose any insecure profiles
467         (such as TCP-only).  The Stack-Proposal of the Response must be
468         equal to the previous test case (i.e. it is independent of the
469         Query's Stack Proposal).
470      Trigger:  Initiator perform Call C. Run other vendor as NSIS
471         Receiver.
472      Note:  Receiver has to offer secure profile.
473
474   o  Test: 1.4
475      Description:  Positive test for re-use of an existing MA.
476      Expected behavior:  The re-use of the existing MA has to be
477         indicated by sending the Response over the existing MA.  The
478         Response must to be confirmed by sending the Confirm message
479         over the same MA and the Confirm should not contain a Stack-
480         Configuration-Data object.
481      Trigger:  Initiator perform Call B, wait 2 second, then perform a
482         Call D. Run other vendor as NSIS Receiver.
483      Note:  It is up to local policy of Responding node whether MA-
484         reuse is performed or not.
485
486   o  Test: 1.5
487      Description:  Positive test for no re-use of an existing MA, if
488         the existing MA does not meet the transport requirements of the
489         Querying node.
490      Expected behavior:  A new MA is established and the Confirm, as
491         well as the Data is sent over that MA.
492      Trigger:  Initiator perform Call B, wait 2 second, then perform a
493         Call H. Run other vendor as NSIS Receiver.
494      Note:
495
496   o  Test: 1.6
497
498
499
500
501
502
503Dickmann                Expires September 2, 2007               [Page 9]
504
505Internet-Draft      GIST Interoperability Test Suite          March 2007
506
507
508      Description:  Positive test for no re-use of an existing MA, if
509         the Peer-Identity in the NLI object has changed.
510      Expected behavior:  A new MA is established and the Confirm, as
511         well as the Data is sent over that MA.
512      Trigger:  Initiator perform Call B, wait 2 second, then perform
513         Call D. Modify the Peer-Identity in the NLI of all messages
514         from the Querying node to the Responding node (i.e.  Query and
515         Confirm) that relate to the second session.  Run other vendor
516         as NSIS Receiver.
517      Note:
518
519   o  Test: 1.7
520      Description:  Positive test for transition from non-reliable
521         transport (D-Mode) to reliable transport (C-Mode).
522      Expected behavior:  GIST has to carry out a new 3-way handshake
523         (Query/Response/Confirm) with a Stack-Proposal negotiation and
524         establish an MA during the handshake.  The test finishes with
525         the Data message being sent over the newly created MA.
526      Trigger:  Initiator perform Call A, wait 2 second, then perform a
527         Call B. Run other vendor as NSIS Receiver.
528      Note:  Wait for next refresh to check if refresh is carried out
529         correctly.
530
531   o  Test: 1.7.2
532      Description:  Positive test for transition from reliable but
533         insecure transport (e.g.  TCP-only) to reliable and secure
534         transport (e.g.  TLS over TCP).
535      Expected behavior:  GIST has to carry out a new 3-way handshake
536         (Query/Response/Confirm) with a Stack-Proposal negotiation and
537         establish a secure MA during the handshake.  The test finishes
538         with the Data message being sent over the newly created MA.
539      Trigger:  Initiator perform Call B, wait 2 second, then perform a
540         Call C. Run other vendor as NSIS Receiver.
541      Note:  Wait for next refresh to check if refresh is carried out
542         correctly.
543
544   o  Test: 1.8
545      Description:  Positive test for no establishment of an MA, which
546         corresponds to a profile from the Stack-Proposal that involves
547         a protocol that has been marked with the D-Flag in the Stack-
548         Configuration-Data.
549      Expected behavior:  All profiles that contain a protocol that has
550         been marked with the D-Flag MUST NOT be used by the Querying
551         node to create an MA.  Instead, one of the remaining profiles
552         has to be used.
553
554
555
556
557
558
559Dickmann                Expires September 2, 2007              [Page 10]
560
561Internet-Draft      GIST Interoperability Test Suite          March 2007
562
563
564      Trigger:  Initiator perform Call B. Mark the protocols that would
565         normally be used with the D-Flag on the path.  Run other vendor
566         as NSIS Receiver.
567      Note:  Which profile would normally be used can be determined by
568         performing Test 1.2.  If the two vendors do not have any
569         profiles left, this test might fail (for example, if TCP is
570         marked with D-Flag and there is no SCTP support to fall back
571         to).
572
573   o  Test: 1.9
574      Description:  Positive test for no re-use of an MA, which
575         corresponds to a profile from the Stack-Proposal that involves
576         a protocol that has been marked with the D-Flag in the Stack-
577         Configuration-Data.
578      Expected behavior:  A new MA is established and the Confirm, as
579         well as the Data is sent over that MA.  The new MA MUST use one
580         of the profiles that does not involve any protocols that have
581         been marked with the D-Flag.
582      Trigger:  Initiator perform Call B, wait 2 second, then perform a
583         Call D. Mark the protocols that would normally be used with the
584         D-Flag on the path after the 3-way handshake of the Call B has
585         been completed.  Run other vendor as NSIS Receiver.
586      Note:  Which profile would normally be used can be determined by
587         performing Test 1.2.  If the two vendors do not have any
588         profiles left, the Call D might fail (for example, if TCP is
589         marked with D-Flag and there is no SCTP support to fall back
590         to), but in no case, the MA should be re-used for the second
591         session.
592
593   o  Test: 1.11
594      Description:  Positive test for setup of an MA, where the MA-
595         Protocol-Options in the Stack-Configuration-Data have the
596         Profile-field set to 0 to indicate "applies to all profiles".
597      Expected behavior:  Establishment of the MA using the protocol
598         information (e.g. port numbers) contained in the "applies to
599         all profiles" MA-Protocol-Options.
600      Trigger:  Initiator perform Call B. If the tested implementation
601         supports sending a Stack-Configuration-Data object of the
602         desired form, this test can be performed without any external
603         trigger mechanism.  Otherwise, if the tested implementation
604         never generates such a Stack-Configuration-Data, the Stack-
605         Configuration-Data object should be altered on the path.  A
606         reasonable strategy is to set the Profile-field of the MA-
607         Protocol-Option that is known to be used to 0 and remove all
608         other Ma-Protocol-Options that deal with the same protocol.
609         Run other vendor as NSIS Receiver.
610
611
612
613
614
615Dickmann                Expires September 2, 2007              [Page 11]
616
617Internet-Draft      GIST Interoperability Test Suite          March 2007
618
619
620      Note:  TBD: Can be do better than this error prone strategy?
621
622
623   Tests related to recoverable problems:
624   o  Test: 1.12
625      Description:  Positive test for retransmit of Query if it was
626         lost.
627      Expected behavior:  Obvious, but add some Text.
628      Trigger:  Initiator perform Call A. First and second Query on the
629         path should be dropped
630      Note:
631
632   o  Test: 1.13
633      Description:  Positive test for establishment of MRS if Response
634         was lost.
635      Expected behavior:  As the Querying node does not receive a
636         Response, it MAY choose to retransmit the Query (with a
637         different Query Cookie), which in turn will trigger a new
638         Response by the Responder.  In addition, as the Responding node
639         does not receive a Confirm, it MAY choose to retransmit the
640         Response.  The exact behavior experienced in this test case is
641         up to the execution of timers and as such unpredictable.
642         However, in any case, the MRS between the peers must be
643         established.
644      Trigger:  Initiator perform Call B. First and second Response on
645         the path should be dropped.
646      Note:  This test case should be performed multiple times with
647         different settings how many Responses are dropped.  (Question:
648         Can we do better than that?  Can we define one (or a set of)
649         test cases that cover all possible message schedules, so that
650         the test case has predictable behavior.)
651
652   o  Test: 1.14
653      Description:  Positive test for retransmit of Response if Confirm
654         was lost.  This test does only apply if the Responder
655         implements that feature (GIST spec states, this feature MAY be
656         implemented).  In case this feature is not implemented,
657         subsequent Data messages will trigger a routing state error
658         message.
659      Expected behavior:  Obvious, but add some Text.  In case this
660         feature is not implemented, subsequent Data messages will
661         trigger a routing state error message.
662      Trigger:  Initiator perform Call A. First and second Confirm on
663         the path should be dropped.
664
665
666
667
668
669
670
671Dickmann                Expires September 2, 2007              [Page 12]
672
673Internet-Draft      GIST Interoperability Test Suite          March 2007
674
675
676      Note:
677
678
679   Tests related to unrecoverable problems:
680   o  Test: 1.15
681      Description:  Negative test where the Querying node demands a
682         secure MA and the Responding node does not offer any secure
683         profiles in its Stack Proposal.  (Bidding down attack).
684      Expected behavior:  The Querying node MUST NOT establish MRS.
685      Trigger:  Initiator perform Call C. Run other vendor as NSIS
686         Receiver.  Remove secure profiles from the Stack-Proposal of
687         the Response on the path.
688      Note:
689
690   o  Test: 1.16
691      Description:  Negative test where the Response does not echo the
692         correct Query Cookie.
693      Expected behavior:  Querying node MUST NOT establish MRS.  (TBD:
694         What is the exact behavior?)
695      Trigger:  Initiator perform Call A. Query Cookie should be altered
696         on the path.  Run other vendor as NSIS Receiver.
697      Note:
698
699   o  Test: 1.17
700      Description:  Negative test where the Confirm does not echo the
701         correct Responder Cookie.
702      Expected behavior:  The Responding node MUST NOT establish MRS.
703         GIST allows Responding nodes to generate an error message in
704         this case (MAY), however the spec states, that this MUST only
705         be enabled selectively.  Therefore, the behavior might either
706         be an "Object Value Error" message sent by the Responding node
707         or a silent drop of the Confirm.  In the latter case, the log
708         of the Responding node needs to be checked to confirm that the
709         Responding node did not establish MRS.
710      Trigger:  Initiator perform Call B. Responder Cookie in Confirm
711         message should be altered on the path.  Run other vendor as
712         NSIS Receiver.
713      Note:
714
715   o  Test: 1.18
716      Description:  Negative test where the Confirm does not echo the
717         correct Stack-Proposal.  This only applies were the Confirm
718         relates to setup of an MA.
719      Expected behavior:  The Responding node MUST terminate the MA and
720         SHOULD log an error condition locally (see Section 5.7.1 of
721         GIST spec).  Furthermore, the Responding node MUST NOT
722         establish MRS.
723
724
725
726
727Dickmann                Expires September 2, 2007              [Page 13]
728
729Internet-Draft      GIST Interoperability Test Suite          March 2007
730
731
732      Trigger:  Initiator perform Call B. Stack-Proposal in Confirm
733         message should be altered on the path.  Run other vendor as
734         NSIS Receiver.
735      Note:  Check the error log of the Responding node to confirm that
736         MRS was not established.
737
738   o  Test: 1.20
739      Description:  Negative test where an on-path attacker tricks the
740         Responding node into re-use of an existing MA, which does not
741         meet the requirements of the Querying node.
742      Expected behavior:  No new MA is established, instead the
743         Responder tries to re-use the existing MA.  The Querying node
744         MUST NOT establish MRS.
745      Trigger:  Initiator perform Call B, wait 2 seconds, then perform a
746         Call H. Remove secure profiles from the Stack-Proposal of the
747         Query on the path.
748      Note:
749
750
751   The test cases defined in this section should be run for any
752   combination of values for these configuration parameters:
753   o  GIST late state installation (possible values: yes/no)
754
7553.2.2.  Refresh of soft state
756
757   After establishing MRS and/or MA GIST implementations must be able to
758   refresh the soft state.  The test setup and roles are equal to the
759   previous section.  GIST implementation MUST pass the following test
760   cases:
761
762   Tests related to normal operation:
763   o  Test: 2.1
764      Description:  Positive test for refreshing Query and Response
765         exchange before Responding node times out.
766      Expected behavior:  If Responding node did not time out (or
767         restart) the Response must not have the R-Flag set and no
768         Confirm should be sent.
769      Trigger:  Initiator perform Call A. Run other vendor as NSIS
770         Receiver.
771      Note:  Test period must be at least 5 minutes.
772
773
774   Tests related to recoverable problems:
775   o  Test: 2.2
776
777
778
779
780
781
782
783Dickmann                Expires September 2, 2007              [Page 14]
784
785Internet-Draft      GIST Interoperability Test Suite          March 2007
786
787
788      Description:  Positive test for refreshing Query and Response
789         exchange after Responding node was restarted.
790      Expected behavior:  The R-Flag of the Response must be set and a
791         Confirm must be sent.
792      Trigger:  Initiator perform Call A. Run other vendor as NSIS
793         Receiver.  After 2 minutes, restart Receiver, then run test for
794         at least 3 minutes.
795      Note:
796
797   o  Test: 2.3
798      Description:  Positive test for retransmit of refreshing Query if
799         Query was lost.
800      Expected behavior:  Query MUST be retransmitted and eventually MRS
801         in the Responding Node must be refreshed.  The Response should
802         not have the R-Flag set and therefore should not trigger a
803         Confirm.
804      Trigger:  Initiator perform Call A. Run other vendor as NSIS
805         Receiver.  After 2 minutes drop the next two Queries,
806         afterwards run test for another 2 minutes.
807      Note:
808
809   o  Test: 2.4
810      Description:  Positive test for retransmit of refreshing Query or
811         Response if Response was lost.  TODO: Be more precise on what
812         can happen.  Query and Response could be retransmitted
813      Expected behavior:  TODO
814      Trigger:  Initiator perform Call A. Run other vendor as NSIS
815         Receiver.  After 2 minutes drop the next two Responses,
816         afterwards run test for another 2 minutes.
817      Note:
818
819   o  Test: 2.5
820      Description:  Positive test for time out of MRS on Querying node
821         if no Response is received to any refreshing Query.
822      Expected behavior:  The MRS on the Querying node has to time out.
823         On a future attempt by the NSLP on the Querying node to send
824         data, GIST has to create new MRS.  The message exchange
825         consists of Query and Response.  As the Responding node
826         receives refreshing Queries the MRS should be kept alive and so
827         when the Querying node creates a new MRS the Response should
828         not contain the R-Flag and thus no Confirm has to be sent.
829      Trigger:  Initiator perform Call A. Run other vendor as NSIS
830         Receiver.  After 25 seconds, drop all Responses on the path for
831         35 seconds.  Perform a new Call A.
832
833
834
835
836
837
838
839Dickmann                Expires September 2, 2007              [Page 15]
840
841Internet-Draft      GIST Interoperability Test Suite          March 2007
842
843
844      Note:  The timing used in the trigger tries to time out MRS on the
845         Querying node, but perform the Call A before the Responding
846         node times out.  It is based on the recommended timer algorithm
847         defined in the GIST specification.  Implementations that do not
848         follow this recommendation have to adjust the timing or use a
849         completely different trigger.
850
851   o  Test: 2.6
852      Description:  Positive test for time out of MRS on Responding node
853         if no refreshing Query is received.
854      Expected behavior:  The MRS on the Querying, as well as on the
855         Responding node has to time out.  A future attempt by the NSLP
856         on the Querying node to send data MUST result in a new 3-way
857         handshake consisting of Query/Response/Confirm.
858      Trigger:  Initiator perform Call A. Run other vendor as NSIS
859         Receiver.  After 40 seconds, drop all Queries on the path for
860         40 seconds.  Perform a new Call A.
861      Note:
862
863   o  Test: 2.7
864      Description:  Positive test that neither Querying nor Responding
865         node close the MA together with the MRS, if the MA-Hold-Time
866         specified by themselves was not yet exceeded.
867      Expected behavior:  The MA MUST NOT be closed together with the
868         time out of the MRS.  Instead, the MA-Hold-Times sent during
869         the 3-way handshake MUST to be honored.
870      Trigger:  Initiator perform Call B. Run other vendor as NSIS
871         Receiver.  After the initial 3-way handshake, drop all Queries
872         on the path.  After 20 seconds, perform another Call B
873         (resetting the MA-Keep-Alive timer, so that the guaranteed MA
874         lifetime exceeds that of the MRS).  Then wait for timeout of
875         MRS and observe if MA is closed.
876      Note:  Based on local policy, both sides MAY decide to send MA-
877         Hello messages to keep the MA open for any number of seconds,
878         even after no MRS exist anymore.
879
880   o  Test: 2.8
881      Description:  Positive test for sending a MA-Hello by the Querying
882         node before the MA-Hold-Time of the Responding node is expired.
883      Expected behavior:  If the MA-Hello message has the R-Flag set and
884         contains a non-zero Hello-ID, the Responding node has to
885         generate a Ma-Hello in response, echoing the received Hello-ID.
886         This MA-Hello sent in response MUST NOT have the R-Flag set.
887         In case the MA-Hello message sent by the Querying node does not
888         have the R-Flag set and does contain a Hello-ID of 0, the
889         Responding node MUST NOT send any message in response.
890         However, in both cases the Responding node MUST reset its MA-
891         Keep-Alive timer and thus not tear down the MA.
892
893
894
895Dickmann                Expires September 2, 2007              [Page 16]
896
897Internet-Draft      GIST Interoperability Test Suite          March 2007
898
899
900      Trigger:  Initiator perform Call B. Increase the MA-Hold-Time
901         advertised by the Querying node to 2 minutes in Query and
902         Confirm on the path or configure the Querying node to do so.
903         Run other vendor as NSIS Receiver.  Wait 60 seconds and observe
904         the MA-Hello exchange.
905      Note:
906
907   o  Test: 2.9
908      Description:  Positive test for sending a MA-Hello by the
909         Responding node before the MA-Hold-Time of the Querying node is
910         expired.
911      Expected behavior:  If the MA-Hello message has the R-Flag set and
912         contains a non-zero Hello-ID, the Querying node has to generate
913         a Ma-Hello in response, echoing the received Hello-ID.  This
914         MA-Hello sent in response MUST NOT have the R-Flag set.  In
915         case the MA-Hello message sent by the Responding node does not
916         have the R-Flag set and does contain a Hello-ID of 0, the
917         Querying node MUST NOT send any message in response.  However,
918         in both cases the Querying node MUST reset its MA-Keep-Alive
919         timer and thus not tear down the MA.
920      Trigger:  Initiator perform Call B. Increase the MA-Hold-Time
921         advertised by the Responding node to 2 minutes in Query and
922         Confirm on the path or configure the Responding node to do so.
923         Run other vendor as NSIS Receiver.  Wait 60 seconds and observe
924         the MA-Hello exchange.
925      Note:
926
927   o  Test: 2.10
928      Description:  Positive test of using the updated MA-Hold-Time of
929         the Confirm, if the Confirm does not echo the MA-Hold-Time of
930         the original Query in the Stack-Configuration-Data.
931      Expected behavior:  The new MA-Hold-Time is used instead of the
932         one in the original Query.
933      Trigger:  Initiator perform Call B. MA-Hold-Time of the Confirm
934         should be altered on the path.  Run other vendor as NSIS
935         Receiver.
936      Note:
937
938
9393.2.3.  Setup of multiple sessions
940
941   GIST implementations must be able to support multiple parallel
942   sessions and must identify a session based on the combination of
943   Message Routing Information (MRI), Session ID (SID) and NSLP
944   Identifier (NSLP ID).  The test setup and roles are equal to the
945   previous section.  GIST implementation MUST pass the following test
946   cases:
947
948
949
950
951Dickmann                Expires September 2, 2007              [Page 17]
952
953Internet-Draft      GIST Interoperability Test Suite          March 2007
954
955
956   Tests related to normal operation:
957   o  Test: 3.1
958      Description:  Positive test for establishing MRS for two sessions,
959         which share MRI and NSLP ID, but have different SIDs.
960      Expected behavior:  A new 3-way handshake has to be performed for
961         the second session.  Afterwards, tefreshing has to be done
962         independently, so refreshing Query and Response messages need
963         to be exchanged for both sessions.
964      Trigger:  Initiator perform Call B, then perform Call D. Run other
965         vendor as NSIS Receiver.
966      Note:  Observe refreshing for 60 seconds.
967
968   o  Test: 3.2
969      Description:  Positive test for establishing MRS for two sessions,
970         which share SID and NSLP ID, but have different MRI (e.g.
971         different port number in PC-MRM).
972      Expected behavior:  The behavior should be identical to the
973         behavior in the previous test case.
974      Trigger:  Initiator perform Call B, then perform Call B, but with
975         an <MRI> that differs in the protocol field.  Run other vendor
976         as NSIS Receiver.
977      Note:
978
979   o  Test: 3.3
980      Description:  Positive test for establishing MRS for two sessions,
981         which share MRI and SID, but have different NSLP ID.
982      Expected behavior:  The behavior should be identical to the
983         behavior in the previous test case.
984      Trigger:  Initiator perform Call B, then perform another Call E.
985         Run other vendor as NSIS Receiver.
986      Note:
987
988   o  Test: 3.4
989      Description:  Positive test of keeping an MA alive, where one of
990         two sessions which share the MA times out.
991      Expected behavior:  The MA has to be kept alive independent of the
992         MRS of one session timing out.  The second session should be
993         refreshed normally.
994      Trigger:  Initiator perform Call B, then perform Call D, then
995         perform Call F (terminates the first session).  Run other
996         vendor as NSIS Receiver.
997      Note:
998
999
10003.2.4.  Interception on NSIS forwarders
1001
1002   While the previous test cases confirm that the basic interaction
1003   between GIST peers work, the following test cases will focus on the
1004
1005
1006
1007Dickmann                Expires September 2, 2007              [Page 18]
1008
1009Internet-Draft      GIST Interoperability Test Suite          March 2007
1010
1011
1012   role of NSIS forwarders.  The test cases require one Querying node
1013   and one Responding node, just like the previous test cases.  However,
1014   the Responding node has to be a router and the destination address of
1015   the MRI of the PC-MRM has to be set to an IP address, so that IP will
1016   route data packets from the Querying node through the Responding
1017   node.  Again, both vendors must be able to take both roles if both
1018   implementations are supposed to work on routers.  If one of the
1019   implementations is designed for end-hosts only, this implementation
1020   MAY skip the role of Responding node for those tests, where it is
1021   supposed to act as NSIS Forwarder.  GIST implementations MUST pass
1022   the following test cases:
1023
1024   Tests related to normal operation:
1025   o  Test: 4.1
1026      Description:  Positive test of interception of the Query message
1027         and successful establishment of MRS between the two peers.
1028         This test case assumes that the Responding node is supporting
1029         the desired NSLP and MRM and the NSLP is interested in the
1030         flow.
1031      Expected behavior:  Query must be intercepted and a 3-way
1032         handshake must be performed, including Response and Confirm.
1033      Trigger:  Initiator perform Call A. Run other vendor as NSIS
1034         Forwarder.
1035      Note:
1036
1037   o  Test: 4.2
1038      Description:  Positive test of forwarding the mostly unchanged
1039         Query message towards the destination IP address and thus no
1040         establishment of MRS, if desired NSLP ID are not supported by
1041         the Responding node.
1042      Expected behavior:  Query has to be forwarded without any changes,
1043         except for a decremented IP-TTL as well as a decremented GIST
1044         hop count.
1045      Trigger:  Initiator perform Call A. Run GIST of other vendor as
1046         NSIS Forwarder, but do not start/register the NSLP.
1047      Note:
1048
1049   o  Test: 4.3
1050      Description:  Positive test of forwarding the unchanged Query
1051         message towards the destination IP address and thus no
1052         establishment of MRS, if Query message is not preceded (word?)
1053         by the magic number (i.e. the message is not properly Q-Mode
1054         encapsulated)
1055      Expected behavior:  Query has to be forwarded without any changes,
1056         except for a decremented IP-TTL.
1057
1058
1059
1060
1061
1062
1063Dickmann                Expires September 2, 2007              [Page 19]
1064
1065Internet-Draft      GIST Interoperability Test Suite          March 2007
1066
1067
1068      Trigger:  Initiator perform Call A, but corrupt magic number in
1069         the Query messages on the path.  Run GIST of other vendor as
1070         NSIS Forwarder.
1071      Note:
1072
1073   o  Test: 4.4
1074      Description:  Positive test of forwarding the unchanged Query
1075         message towards the destination IP address and thus no
1076         establishment of MRS, if the desired MRM is not supported by
1077         the Responding node.
1078      Expected behavior:  Query has to be forwarded without any changes,
1079         except for a decremented IP-TTL.  (Question: Is that correct?
1080         There is no error defined, but I can't find the correct
1081         behavior in the draft.  If forwarding is correct, is GHC
1082         decremented?)
1083      Trigger:  Initiator perform Call A. Modify the MRM-ID field of the
1084         MRI in the Query message to 120 (or any other Private/
1085         Experimental Use value) on the path.  Run GIST of other vendor
1086         as NSIS Forwarder.
1087      Note:
1088
1089
1090   Tests related to error conditions:
1091   o  Test: 4.6
1092      Description:  Positive test of generation of an "Unknown NSLPID"
1093         error message, if a normal encapsulated Data message is
1094         received on the Responding node, which does not support the
1095         desired NSLP ID.
1096      Expected behavior:  "Unknown NSLPID" error message MUST be
1097         generated.
1098      Trigger:  Initiator perform Call A. Restart GIST on Responder
1099         node, but without the used NSLP.  Perform another Call A. Run
1100         GIST of other vendor as NSIS Receiver.
1101      Note:
1102
1103   o  Test: 4.7
1104      Description:  Positive test of generation of an "Endpoint Found"
1105         error message, if a Query message arrives on a end-host that
1106         does not support the desired NSLP.
1107      Expected behavior:  "Endpoint Found" error message MUST be
1108         generated.
1109      Trigger:  Initiator perform Call A. Run GIST of other vendor as
1110         NSIS Receiver, but without starting/registering the desired
1111         NSLP.
1112
1113
1114
1115
1116
1117
1118
1119Dickmann                Expires September 2, 2007              [Page 20]
1120
1121Internet-Draft      GIST Interoperability Test Suite          March 2007
1122
1123
1124      Note:
1125
1126
11273.2.5.  GIST Stateless operation
1128
1129   GIST is capable of a stateless operation, where no 3-way handshake is
1130   performed and thus no Message Routing State is established.  In this
1131   mode of operation GIST sends the NSLP payload inside Q-Mode
1132   encapsulated DATA messages.  GIST implementations supporting the
1133   stateless mode of operation MUST pass the following test cases:
1134
1135   Tests related to normal operation:
1136   o  Test: 5.1
1137      Description:  Positive test of interception of a Q-Mode
1138         encapsulated Data message on an NSIS Forwarder.
1139      Expected behavior:  NSLP payload contained in the Data message is
1140         delivered to the NSLP.
1141      Trigger:  Initiator perform Call G. Run other vendor as NSIS
1142         Forwarder.
1143      Note:
1144
1145   o  Test: 5.2
1146      Description:  Positive test of reception of the Q-Mode
1147         encapsulated Data message by the NSIS Receiver.
1148      Expected behavior:  NSLP payload contained in the Data message is
1149         delivered to the NSLP.
1150      Trigger:  Initiator perform Call G. Run other vendor as NSIS
1151         Receiver.
1152      Note:
1153
1154
11553.2.6.  Message composition
1156
1157   TDB: Tests that deal with wrong message composition.
1158
1159   Tests related to error conditions:
1160   o  Test: 6.1
1161      Description:  Positive test of generation of an "Object Type
1162         Error" message, if the Query does not contain a Session ID
1163         object (mandatory).
1164      Expected behavior:  "Object Type Error" must be generated.
1165      Trigger:  TDB: How to trigger this?
1166      Note:  TDB: Question: Strictly speaking, this is not an INTEROP
1167         test.  Should it be part of this test suite?  If yes, should it
1168         be part of a seperate section dealing with robustness and
1169         sanity checks?
1170
1171
1172
1173
1174
1175Dickmann                Expires September 2, 2007              [Page 21]
1176
1177Internet-Draft      GIST Interoperability Test Suite          March 2007
1178
1179
1180
1181
11823.2.7.  Upstream Queries
1183
1184   TDB: Tests that deal with upstream Queries.
1185
1186   Tests related to normal operation:
1187   o  Test: 7.1
1188      Description:  Positive test for establishment of MRS in the
1189         upstream direction, i.e. the Querying node sends a Query
1190         upstream to the Responding node.
1191      Expected behavior:  Establishment of MRS.
1192      Trigger:
1193      Note:
1194
1195
11963.2.8.  NAT Traversal
1197
1198   TDB: Tests that deal with NAT Traversal.
1199
1200   Tests related to normal operation:
1201   o  Test: 8.1
1202      Description:  Positive test for detection of a Legacy NAT by the
1203         NSIS Initiator located on the internal side of the NAT.
1204      Expected behavior:  As the Querying node is the NSIS Initiator,
1205         all Queries will have the S-Flag set.  Thus, the receiver MUST
1206         detect the translation done by the NAT and generate a "Object
1207         Type Error" message with subcode 4 ("Untranslated Object")
1208         indicating the MRI as the object in question.  The Querying
1209         node MUST terminate the 3-way handshake immediately.
1210      Trigger:  Initiator perform Call A. Run other vendor as NSIS
1211         Receiver.  The Non-NSIS Forwarder has to act as a GIST-unaware
1212         Legacy NAT, with the NSIS Initiator being on the internal side
1213         and the NSIS Receiver being on the external side of the NAT.
1214      Note:
1215
1216   o  Test: 8.2
1217      Description:  Positive test for detection of a Legacy NAT by a
1218         Querying node located on the internal side of the NAT.  The
1219         Querying node MUST NOT be the NSIS Initiator.
1220      Expected behavior:  If the initial Query and all subsequent
1221         retransmitted ones do not have the S-Flag set (i.e. the source
1222         IP address of the Query is the source address of the flow and
1223         not the IP address of the Querying node) the Legacy NAT
1224         detection defined in [1] will fail.  In this case, the Querying
1225         node does not violate the GIST specification, but does not
1226         follow the recommendations either.
1227         If the initial Query or any retransmitted Query has the S-Flag
1228
1229
1230
1231Dickmann                Expires September 2, 2007              [Page 22]
1232
1233Internet-Draft      GIST Interoperability Test Suite          March 2007
1234
1235
1236         set, the situation changes.  In this case, the receiver MUST
1237         detect the translation done by the NAT and generate a "Object
1238         Type Error" message with subcode 4 ("Untranslated Object")
1239         indicating the MRI as the object in question.  The Querying
1240         node MUST terminate the 3-way handshake immediately.
1241      Trigger:  Initiator perform Call J. Run other vendor as NSIS
1242         Receiver.  The Non-NSIS Forwarder has to act as a GIST-unaware
1243         Legacy NAT, with the Initiator being on the internal side and
1244         the NSIS Receiver being on the external side of the NAT.
1245      Note:  Strictly speaking, the Initiator in this test case is not
1246         the NSIS Initiator.  Instead, the Initiator acts as a proxy.
1247         Note that the Initiator has to be on the path between the
1248         chosen flow source address and the NSIS Receiver.
1249
1250   o  Test: 8.3
1251      Description:  Positive test for detection of a Legacy NAT by the
1252         NSIS Initiator located on the external side of the NAT.  This
1253         test case only applies if the Legacy NAT is statically
1254         configured to forward GIST Q-mode traffic to a node on the
1255         internal side of the NAT.
1256      Expected behavior:  The Responding will generate a Response
1257         unaffected by the presence of a NAT.  The Response will be
1258         translated by the NAT, just like any UDP traffic.  The Querying
1259         MUST detect that the NAT by comparing the source address in the
1260         IP header with the NLI of the Response and terminate the 3-way
1261         handshake.
1262      Trigger:  Initiator perform Call A. Run other vendor as NSIS
1263         Receiver.  The Non-NSIS Forwarder has to act as a GIST-unaware
1264         Legacy NAT, with the NSIS Initiator being on the external side
1265         and the NSIS Receiver being on the internal side of the NAT.
1266      Note:
1267
1268
12693.3.  Additional
1270
12713.3.1.  GIST transport protocols
1272
1273   TODO
1274   o  Positive test of negotiation and use of SCTP as the transport
1275      protocol for GIST.
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287Dickmann                Expires September 2, 2007              [Page 23]
1288
1289Internet-Draft      GIST Interoperability Test Suite          March 2007
1290
1291
12924.  Definition of Interop/Testing NSLP
1293
12944.1.  Overview
1295
1296   The Interop/testing NSLP is a very simple NSLP.  Every message
1297   consists of only two 32-bit fields: An NSLP HopCount and a sequence
1298   number.
1299
1300   The processing on NSIS Forwarders is as follows:
1301   o  Increase the NSLP HopCount by one
1302   o  Forward the message in the same direction it was received
1303
1304   The processing on the NSIS Receiver is as follows:
1305   o  Increase the NSLP HopCount by one
1306   o  Forward the message in the upstream direction
1307
1308   The operation of the NSIS Initiator is as follows:
1309   o  Send a new message with NSLP HopCount set to zero and set the
1310      sequence number to a unique value.  Send message in the downstream
1311      direction.
1312   o  Wait for reception of a message that matches the sequence number
1313      chosen for the sent message.  Give up after 15 seconds.
1314
1315   In order to use this very simple NSLP for GIST interop testing, the
1316   major part of the Interop NSLP specification deals with the use of
1317   the GIST API.  The tests described in this document require the NSLP
1318   to request several kinds of services from GIST.  The Interop NSLP
1319   will provide explicitly defined values for all GIST API parameters in
1320   the following.
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343Dickmann                Expires September 2, 2007              [Page 24]
1344
1345Internet-Draft      GIST Interoperability Test Suite          March 2007
1346
1347
13485.  Security Considerations
1349
1350   This document defines test cases and therefore tests various aspects
1351   of the GIST specification.
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399Dickmann                Expires September 2, 2007              [Page 25]
1400
1401Internet-Draft      GIST Interoperability Test Suite          March 2007
1402
1403
14046.  IANA Considerations
1405
1406   This document does not require actions by IANA.
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455Dickmann                Expires September 2, 2007              [Page 26]
1456
1457Internet-Draft      GIST Interoperability Test Suite          March 2007
1458
1459
14607.  Acknowledgments
1461
1462   The author would like to thank Roland Bless, Alan Ford and Andrew
1463   McDonald for their helpful suggestions.
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511Dickmann                Expires September 2, 2007              [Page 27]
1512
1513Internet-Draft      GIST Interoperability Test Suite          March 2007
1514
1515
15168.  References
1517
15188.1.  Normative References
1519
1520   [1]  Schulzrinne, H. and R. Hancock, "GIST: General Internet
1521        Signalling Transport", draft-ietf-nsis-ntlp-13 (work in
1522        progress), April 2007.
1523
15248.2.  Informative References
1525
1526   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
1527        Levels", BCP 14, RFC 2119, March 1997.
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567Dickmann                Expires September 2, 2007              [Page 28]
1568
1569Internet-Draft      GIST Interoperability Test Suite          March 2007
1570
1571
1572Author's Address
1573
1574   Christian Dickmann
1575   University of Goettingen
1576   Institute for Informatics
1577   Lotzestr. 16-18
1578   Goettingen  37083
1579   Germany
1580
1581   Email: mail@christian-dickmann.de
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623Dickmann                Expires September 2, 2007              [Page 29]
1624
1625Internet-Draft      GIST Interoperability Test Suite          March 2007
1626
1627
1628Full Copyright Statement
1629
1630   Copyright (C) The IETF Trust (2007).
1631
1632   This document is subject to the rights, licenses and restrictions
1633   contained in BCP 78, and except as set forth therein, the authors
1634   retain all their rights.
1635
1636   This document and the information contained herein are provided on an
1637   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1638   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1639   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1640   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1641   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1642   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1643
1644
1645Intellectual Property
1646
1647   The IETF takes no position regarding the validity or scope of any
1648   Intellectual Property Rights or other rights that might be claimed to
1649   pertain to the implementation or use of the technology described in
1650   this document or the extent to which any license under such rights
1651   might or might not be available; nor does it represent that it has
1652   made any independent effort to identify any such rights.  Information
1653   on the procedures with respect to rights in RFC documents can be
1654   found in BCP 78 and BCP 79.
1655
1656   Copies of IPR disclosures made to the IETF Secretariat and any
1657   assurances of licenses to be made available, or the result of an
1658   attempt made to obtain a general license or permission for the use of
1659   such proprietary rights by implementers or users of this
1660   specification can be obtained from the IETF on-line IPR repository at
1661   http://www.ietf.org/ipr.
1662
1663   The IETF invites any interested party to bring to its attention any
1664   copyrights, patents or patent applications, or other proprietary
1665   rights that may cover technology that may be required to implement
1666   this standard.  Please address the information to the IETF at
1667   ietf-ipr@ietf.org.
1668
1669
1670Acknowledgment
1671
1672   Funding for the RFC Editor function is provided by the IETF
1673   Administrative Support Activity (IASA).
1674
1675
1676
1677
1678
1679Dickmann                Expires September 2, 2007              [Page 30]
1680
1681