TOC 
NSISX. Fu
Internet-DraftI. Juchem
Expires: May 7, 2006C. Dickmann
 Univ. Goettingen
 H. Tschofenig
 Siemens
 November 3, 2005

Design Options of NSIS Diagnostics NSLP

draft-fu-nsis-diagnostics-nslp-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 7, 2006.

Copyright Notice

Copyright © The Internet Society (2005).

Abstract

The Next Steps in Signaling protocol suite aims to provide a way to communicate with network intermediaries. As such, it is desirable to offer generic diagnostics function for NSIS users and system administrators to make the functionality provided by the network more transparent (e.g., to identify particular NSLPs, to determine to which degree the network supports NSIS, GIST state or specific NSLP session information along a given path).

Instead of suggesting one specific solution we highlight the different design options of some simple, stateless diagnostics functions from a querying node to a responding node. These preliminary thoughts should help the working group to have a more structure discussion in this problem space.



Table of Contents

1.  Introduction
2.  Information to be Diagnosed
3.  Information gathering and data transport options
    3.1.  Basic prerequisites
        3.1.1.  Basic message objects
    3.2.  NTLP state information
        3.2.1.  General GIST state information
        3.2.2.  SID-bound state information
    3.3.  NSLP state information
        3.3.1.  NSLP state information object
    3.4.  Query available NSLPs
        3.4.1.  Available NSLPs object
    3.5.  Additional information
4.  Security Considerations
5.  Summary and Open Issues
6.  IANA Considerations
7.  Acknowledgments
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1. Introduction

The lack of a unified mechanism for diagnostics capabilities in the NSIS protocol suite represents a substantial problem, for both the end user and the system administrator. As the number of vendors and operators deploying (and possibly extended) NSIS is expected to increase, the problem of diagnosing the multitude of devices from different signaling functions, both for general signaling transport and for particular signaling applications, escalates. Although some NSLP specifications set out the details of how a device can enquire some sort of diagnostics data, the extent to which this diagnostics data is used and converted to meaningful information by the specific NSLPs varies considerably from one NSLP to another. For instance, in the current version of QoS-NSLP specification [1] (Bosch, S., “NSLP for Quality-of-Service signalling,” October 2005.), Query messages are used for detecting path characteristics information from any QNE towards a QNI. In the case of NATFW NSLP, current specification [2] (Stiemerling, M., “NAT/Firewall NSIS Signaling Layer Protocol (NSLP),” October 2005.) defines a Query and Diagnostics Request message used by authorized NATFW NEs for querying and diagnosing installed NATFW states and it is still in discussion whether to exclude this feature from the base specification of the NATFW NSLP. On the other hand, GIST [3] (Schulzrinne, H. and R. Hancock, “GIST: General Internet Signaling Transport,” September 2005.) does not provide an explicit diagnostics function to allow authorized entities to diagnose the GIST level information; it simply discovers the next GIST peer and delivers NSLP messages as its payload.

It is expected that the additional administrative or development effort is required without diagnostic capabilities. RSVP's diagnostics functions (see [4] (Terzis, A., Braden, B., Vincent, S., and L. Zhang, “RSVP Diagnostic Messages,” January 2000.)) allow any RSVP node to query a RSVP session's Path state and Resv state (if available). However they exhibit a lack of the the capability of performing authorized access, which may be desired to prevent the introduction of security vulnerabilities (see [5] (Tschofenig, H., “RSVP Security Properties,” February 2005.)).

This document describes some key design considerations towards a set of simple, generic and secure diagnostics functions. The following aspects seem to be major design decisions:

Subsequent sections will discuss these aspects in more details.



 TOC 

2. Information to be Diagnosed

The main purpose of diagnostics NSLP is to diagnose NSIS state information. One question is which state could and should be diagnosed, and how much granularity of the state should be possible to be diagnosed. Corresponding to the 2-layer architecture of NSIS, there are two types of NSIS states: GIST and NSLP state information. In case of GIST (or NTLP) state, we also distinguish between state information we want to collect for states corresponding to one single Session ID (SID), further labeled "SID-bound state information", and state information to be collected which is not directly corresponding to a SID (further called "General GIST state information". We will list a few state information elements below:

General GIST state information:

GIST state includes:
MA information:
The MA information might include a list of the message associations a GIST node has currently in use. This involves the properties of the MA, e.g. the used protocol stack, the address of the corresponding peer and the list of MRS using the MA. In addition a general information about the supported protocol stacks (in respect of the GIST stack proposal) should be included in the diagnostics data.

GIST MRS information:
An exhaustive list of the MRS table might cause the size of a diagnostics messages to increase dramatically, for example, when the core node supporting tens of thousands of sessions. It may also be not very helpful and also not secure without being scoped to a limited network domain. However, the total numbers of MRSs over an individual MAs in a GIST node may be of interest to the entity performing the diagnostics function.
SID-bound state information:

For state information which is directly corresponding to one single GIST Session ID/NSLPid tupel, more detailed information can be collected. This includes, but does not limit to, the following information:
MA information:
In contrast to the general GIST state case, the MA information for the SID-bound state information is limited to the message associations related to the specific SessionID/NSLPID tupel.
MRS information:
The MRS data might include the MRI and information about the upstream and downstream peers, as well as configuration values, such as refresh intervals.
NSLP state:

It is likely possible to collect some information about the NSLP state corresponding to a particular session ID, if the authorization issue is addressed. However, it should not allow a diagnostics message from any querying node to query state belonging to other sessions or other NSLPs not being the present node (requestor). For NAT/FW NSLP, it may be interesting for a requestor to be able to diagnose the existence of NAT and FW devices (their IP addresses) and if possible, number or detailed information of NAT bindings or firewall entries, without a per-session basis. However, this is subject to authorization decisions in the protocol operation. Also, the QOS NSLP can be diagnosed for various information.

In addition, collecting general information such as GIST supporting information (e.g., GIST node IP addresses) or in the case of QoS NSLP, QOSM ID supporting information in the QoS NSLP supporting nodes may be possible.

Furthermore, if necessary, one can also calculate the processing delay information in GIST nodes, by putting timestamps to the diagnostics messages when they traverse a GIST node. This simple extension, similar to traceroute, can be added to diagnostics messages as discussed in [6] (Juchem, I., “A stateless Ping tool for simple tests of GIMPS implementations,” July 2005.).

The final information we propose to be gathered from NSIS nodes is their support for different NSLPs. It would certainly be interesting to provide means to query existing (and thereby supported) NSLPs on a GIST node. Whether one GIST node supports none, one or even multiple different NSLPs will help diagnose potential problems or even security threats, which a "forgotten" NSLP on one node could pose to the GIST setup.



 TOC 

3. Information gathering and data transport options

This section will describe conditions and basic usage along with a proposed message format for GIST diagnostics client messages. It will also highlight practical usage for different scenarios.



 TOC 

3.1. Basic prerequisites

It is desirable that a diagnostics function does not install any new state. However sometimes this is inevitable, for example state in GIST level, especially MRS state even no new MAs will be introduced. It is possible that the diagnostics messages will be transported in a stateless mode and the response messages are directly addressed to the requestor, if it is not necessary to maintain reverse routing information and modify/add results in the reverse direction. On the other hand, if a new MRS needs to be created in querying direction, then it should be removed in the response direction. Therefore, to avoid state creation on NTLP level, diagnostics messages should be kept as small as possible.

Diagnostics messages should be limited to fit into a D-mode (e.g., UDP) message in size, thus no larger than 64k and likely limited by the link MTU.

For simplicity and easy implementation we will continue NSIS' message object approach. This means that messages created by the diagnostic tool will consist of several objects which themselves could be compiled by adding various other message objects. By this, we also enable easy extensibility for further information gathering of yet unknown NSLPs.

Messages by the diagnostics tool consist of one common header followed by a Query object and a list of Hop objects:

DIAGNOSTIC-message =
Common header, Query object, [Hop object]*

The Query object specifies the requested information every GIST node should add. A Hop object is added by every GIST node on the path and contains the requested information. The Hop object itself consists of a Hop-Header and a list of data objects:

Hop-object =
Hop header
[IPv4 address object]*
[IPv6 address object]*
[General GIST information object]
[SID-bound Response object]
[NSLP state information object]
[Available NSLPs object]
[Additional information object]

The procedure for the diagnostic tools will be as follows:

  1. At querying node, compose and send query message with designated destination - the final GIST node along the path
  2. GIST at querying node forwards message to next GIST node towards the destination
  3. Intermediate Diagnostic-NSLP-aware GIST nodes add queried information if message is on the downstream direction and forward to next peer
  4. The destination GIST node adds queried information and forwards the message in the upstream direction

The message flow is depicted in Figure 1.


+----------+    +----------+                    +----------+
|          |    |          |                    |          |
|Diagnostic|    |Diagnostic|                    |Diagnostic|
|   NSLP   |    |   NSLP   |                    |   NSLP   |
|          |    |          |                    |          |
+----------+    +----------+                    +----------+
1. || /\        3. /\  ||                       4. /\  ||
   \/ ||           ||  \/                          ||  \/
 +--------+2.    +--------+      +--------+      +--------+
 |        |>>>>>>|        |>>>>>>|        |> .. >|        |
 |  GIST  |      |  GIST  |      |  GIST  |      |  GIST  |
 |  node  |      |  node  |      |  node  |      |  node  |
 |        |<<<<<<|        |<<<<<<|        |< .. <|        |
 +--------+      +--------+      +--------+      +--------+
                   >> Upstream query message
                   << Downstream response message

              Figure 1: Diagnostic NSLP message flow


 TOC 

3.1.1. Basic message objects



 TOC 

3.1.1.1. Common Header


 0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Version    |   Length      |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version : Identifier for diagnostic NSLP
Length : Overall message length



 TOC 

3.1.1.2. Standard Object Format

Each object begins with a fixed header giving the object Type and object Length. This is followed by the object Value, which is a whole number of 32-bit words long.


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|r|r|r|r|         Type          |r|r|r|r|        Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                             Value                           //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Type 00 : Query object
Type 01 : Hop object
Type 02 : IPv4 address object
Type 03 : IPv6 address object
Type 04 : General GIST information object
Type 05 : SID-bound Response object
Type 06 : NSLP state information object
Type 07 : Available NSLPs object
Type 08 : Additional information object object



 TOC 

3.1.1.3. Hop object

The hop object is just a container for the information objects requested in the Query object.



 TOC 

3.1.1.4. IPv4 address object

Every Hop Object may contain any number of IPv4 address objects.

Length: 4 bytes


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         IPv4 address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



 TOC 

3.1.1.5. IPv6 address object

Every Hop Object may contain any number of IPv6 address objects.

Length: 16 bytes


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                         IPv6 address                          |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



 TOC 

3.2. NTLP state information

As described earlier, we distinguish between general GIST state information and SID-bound state information. When collecting general GIST state information, one has to be careful to limit the amount of gathered information to comply to the basic prerequisites, especially in terms of expected message sizes. For example, when querying for larger sized information the possible maximum amount of nodes the query collects data from and replies it to the querying node, has to be taken into account to not exceed the maximum allowed message size and thereby risk the loss of data.



 TOC 

3.2.1. General GIST state information

This will be discussed in a later version



 TOC 

3.2.2. SID-bound state information

This will be discussed in a later version



 TOC 

3.3. NSLP state information

Which information to collect about states linked to a specific SID depends on the NSLP being queried. However, some basic information common to all NSLPs could still be gathered, for example the total amount of states connected to a specific SID.



 TOC 

3.3.1. NSLP state information object

NSLP state information object.

Length: Variable


 0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NSLP ID       |    Length     |       Reserved                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|InformationType| Value                                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
|InformationType| Value                                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


NSLP ID: Identifier for queried NSLP
Length : Overall message length
InformationType : Identifier for information that is to be queried on GIST nodes up to destination
Value : Value of queried information

Information Type could be any data queried at a GIST node which could be used for diagnosis. Example: Total amount of states maintained by a QoS NSLP, Value would then contain that amount. When acting as a query message, only the InformationType fields will be present and contain the identifier. Intermediate GIST nodes and the destination GIST node will then enter the values accordingly. This would also allow for querying multiple types of information.

GIST nodes not able to provide the requested information enter a value of 0 if they couldn't provide the information due to non availability and -1 if an error occured into the specific value field



 TOC 

3.4. Query available NSLPs

This scenario can be expected to be most widely used. Also, it should be the most easiest one to deploy and implement aswell as gather the requested information. The diagnostics NSLP simply queries for other NSLP IDs on the GIST nodes, collects them and adds their values to the RESPONSE object together with the total amount of IDs and finally its IP address.



 TOC 

3.4.1. Available NSLPs object

Available NSLPs object lists the NSLP IDs supported at the given GIST node.

Length: Variable (depends on the number of NSLPs supported on the GIST node)


 0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Length     |   Reserved    | ID of 1st NSLP                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ID of 2nd NSLP                 | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ...                          | Id of nth NSLP                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length : Overall message length
ID of Xth NSLP : NSIS ID of NSLP existing and supported by GIST node



 TOC 

3.5. Additional information

Additional information can be gathered by computing the minimum, maximum and average delay of a roundtrip with values collected by running an instance of the PING Deamon. Other possible data to be queried for can include the software version of GIST, the OS running GIST, amount of known peers and other useful information.



 TOC 

4. Security Considerations

Authorization and protection of the diagnostics messages seem to be two outstanding issues, among the various issues identified in [7] (Tschofenig, H. and D. Kroeselberg, “Security Threats for Next Steps in Signaling (NSIS),” June 2005.).

On one hand, one may desire that only the state installer can query the session-specific state. For general information diagnostics, measures may be desired for allowing administrators only be able to make the operations across their own domains, or neighboring trusted domains.

On the other hand, the diagnostics messages carry senstive information that needs to be integrity protected. Some measures may be utilized such as reusing the secure MAs (if available) between the neigboring GIST nodes, or add NSLP level security mechanisms such as CMS.

A future version of this document will add more security relevant considerations.



 TOC 

5. Summary and Open Issues

We have discussed in this document how diagnostics functions for NSIS implementations as a common NSLP could be designed. Our intention is to keep it as simple and secure as possible.

Further possible additions to the diagnostics function could be diagnostics support for tunnelling and mobility devices.

A new NSLP ID needs to be defined if a common NSLP for diagnostics functions is devised.



 TOC 

6. IANA Considerations

A future version of this document will provide details about an IANA consideration.



 TOC 

7. Acknowledgments

The authors would like to thank Sebastian Willert, Henning Peters and Luis Cordeiro for the discussion and implementation of the early ideas, as well as John Loughney, Jukka Manner, Robert Hancock, Andrew McDonald and Bernd Schloer for their feedback.



 TOC 

8. References



 TOC 

8.1. Normative References

[1] Bosch, S., “NSLP for Quality-of-Service signalling,” draft-ietf-nsis-qos-nslp-08 (work in progress), October 2005.
[2] Stiemerling, M., “NAT/Firewall NSIS Signaling Layer Protocol (NSLP),” draft-ietf-nsis-nslp-natfw-08 (work in progress), October 2005.
[3] Schulzrinne, H. and R. Hancock, “GIST: General Internet Signaling Transport,” draft-ietf-nsis-ntlp-08 (work in progress), September 2005.


 TOC 

8.2. Informative References

[4] Terzis, A., Braden, B., Vincent, S., and L. Zhang, “RSVP Diagnostic Messages,” RFC 2745, January 2000.
[5] Tschofenig, H., “RSVP Security Properties,” draft-ietf-nsis-rsvp-sec-properties-06 (work in progress), February 2005.
[6] Juchem, I., “A stateless Ping tool for simple tests of GIMPS implementations,” draft-juchem-nsis-ping-tool-02 (work in progress), July 2005.
[7] Tschofenig, H. and D. Kroeselberg, “Security Threats for Next Steps in Signaling (NSIS),” RFC 4081, June 2005.


 TOC 

Authors' Addresses

  Xiaoming Fu
  University of Goettingen
  Institute for Informatics
  Lotzestr. 16-18
  Goettingen 37083
  Germany
Email:  fu@cs.uni-goettingen.de
  
  Ingo Juchem
  University of Goettingen
  Institute for Informatics
  Lotzestr. 16-18
  Goettingen 37083
  Germany
Email:  ijuchem@cs.uni-goettingen.de
  
  Christian Dickmann
  University of Goettingen
  Institute for Informatics
  Lotzestr. 16-18
  Goettingen 37083
  Germany
Email:  mail@christian-dickmann.de
  
  Hannes Tschofenig
  Siemens
  Otto-Hahn-Ring 6
  Munich, Bayern 81739
  Germany
Email:  Hannes.Tschofenig@siemens.com


 TOC 

Intellectual Property Statement

Disclaimer of Validity

Copyright Statement

Acknowledgment