idnits 2.17.00 (12 Aug 2021) /tmp/idnits21313/draft-fu-nsis-diagnostics-nslp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 660. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 644. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 650. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 6, 2006) is 5919 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-nsis-qos-nslp has been published as RFC 5974 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-qos-nslp (ref. '1') == Outdated reference: draft-ietf-nsis-nslp-natfw has been published as RFC 5973 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-nslp-natfw (ref. '2') == Outdated reference: draft-ietf-nsis-ntlp has been published as RFC 5971 ** Downref: Normative reference to an Experimental draft: draft-ietf-nsis-ntlp (ref. '3') Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NSIS X. Fu 3 Internet-Draft I. Juchem 4 Expires: September 7, 2006 C. Dickmann 5 Univ. Goettingen 6 H. Tschofenig 7 Siemens 8 March 6, 2006 10 Design Options of NSIS Diagnostics NSLP 11 draft-fu-nsis-diagnostics-nslp-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 7, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 The Next Steps in Signaling protocol suite aims to provide a way to 45 communicate with network intermediaries. As such, it is desirable to 46 offer generic diagnostics function for NSIS users and system 47 administrators to make the functionality provided by the network more 48 transparent (e.g., to identify particular NSLPs, to determine to 49 which degree the network supports NSIS, GIST state or specific NSLP 50 session information along a given path). 52 Instead of suggesting one specific solution we highlight the 53 different design options of some simple, stateless diagnostics 54 functions from a querying node to a responding node. These 55 preliminary thoughts should help the working group to have a more 56 structure discussion in this problem space. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Information to be Diagnosed . . . . . . . . . . . . . . . . . 3 62 3. Information gathering and data transport options . . . . . . . 5 63 3.1. Basic prerequisites . . . . . . . . . . . . . . . . . . . 5 64 3.1.1. Basic message objects . . . . . . . . . . . . . . . . 7 65 3.2. NTLP state information . . . . . . . . . . . . . . . . . . 9 66 3.2.1. General GIST state information . . . . . . . . . . . . 10 67 3.2.2. SID-bound state information . . . . . . . . . . . . . 10 68 3.3. NSLP state information . . . . . . . . . . . . . . . . . . 11 69 3.3.1. NSLP state information object . . . . . . . . . . . . 11 70 3.4. Query available NSLPs . . . . . . . . . . . . . . . . . . 12 71 3.4.1. Available NSLPs object . . . . . . . . . . . . . . . . 12 72 3.5. Additional information . . . . . . . . . . . . . . . . . . 12 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 5. Summary and Open Issues . . . . . . . . . . . . . . . . . . . 13 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 81 Intellectual Property and Copyright Statements . . . . . . . . . . 16 83 1. Introduction 85 The lack of a unified mechanism for diagnostics capabilities in the 86 NSIS protocol suite represents a substantial problem, for both the 87 end user and the system administrator. As the number of vendors and 88 operators deploying (and possibly extending) NSIS is expected to 89 increase, the problem of diagnosing the multitude of devices from 90 different signaling functions, both for general signaling transport 91 and for particular signaling applications, escalates. Although some 92 NSLP specifications set out the details of how a device can enquire 93 some sort of diagnostics data, the extent to which this diagnostics 94 data is used and converted to meaningful information by the specific 95 NSLPs varies considerably from one NSLP to another. For instance, in 96 the current version of QoS-NSLP specification [1], Query messages are 97 used for detecting path characteristics information from any QNE 98 towards a QNI. In the case of NATFW NSLP, current specification [2] 99 defines a Query and Diagnostics Request message used by authorized 100 NATFW NEs for querying and diagnosing installed NATFW states and it 101 is still in discussion whether to exclude this feature from the base 102 specification of the NATFW NSLP. On the other hand, GIST [3] does 103 not provide an explicit diagnostics function to allow authorized 104 entities to diagnose the GIST level information; it simply discovers 105 the next GIST peer and delivers NSLP messages as its payload. 107 It is expected that the additional administrative or development 108 effort is required without diagnostic capabilities. RSVP's 109 diagnostics functions (see [4]) allow any RSVP node to query a RSVP 110 session's Path state and Resv state (if available). However they 111 exhibit a lack of the the capability of performing authorized access, 112 which may be desired to prevent the introduction of security 113 vulnerabilities (see [5]). 115 This document describes some key design considerations towards a set 116 of simple, generic and secure diagnostics functions. The following 117 aspects seem to be major design decisions: 118 o Which information is going to be subject for diagnosis? 119 o At which granularity of the information can be diagnosed? 120 o Which transport mechanism should be used for delivering 121 diagnostics messages, and whether to introduce/avoid GIST level 122 and/or NSLP state 123 o How to properly authorize a diagnostics operation and protect the 124 diagnostics messages? 126 Subsequent sections will discuss these aspects in more details. 128 2. Information to be Diagnosed 129 The main purpose of diagnostics NSLP is to diagnose NSIS state 130 information. One question is which state could and should be 131 diagnosed, and how much granularity of the state should be possible 132 to be diagnosed. Corresponding to the 2-layer architecture of NSIS, 133 there are two types of NSIS states: GIST and NSLP state information. 134 In case of GIST (or NTLP) state, we also distinguish between state 135 information we want to collect for states corresponding to one single 136 Session ID (SID), further labeled "SID-bound state information", and 137 state information to be collected which is not directly corresponding 138 to a SID (further called "General GIST state information". We will 139 list a few state information elements below: 140 General GIST state information: 142 GIST state includes: 143 MA information: The MA information might include a list of the 144 message associations a GIST node has currently in use. This 145 involves the properties of the MA, e.g. the used protocol 146 stack, the address of the corresponding peer and the list of 147 MRS using the MA. In addition a general information about the 148 supported protocol stacks (in respect of the GIST stack 149 proposal) should be included in the diagnostics data. 151 GIST MRS information: An exhaustive list of the MRS table might 152 cause the size of a diagnostics messages to increase 153 dramatically, for example, when the core node supporting tens 154 of thousands of sessions. It may also be not very helpful and 155 also not secure without being scoped to a limited network 156 domain. However, the total numbers of MRSs over an individual 157 MAs in a GIST node may be of interest to the entity performing 158 the diagnostics function. 160 SID-bound state information: 162 For state information which is directly corresponding to one 163 single GIST Session ID/NSLPid tupel, more detailed information can 164 be collected. This includes, but does not limit to, the following 165 information: 166 MA information: In contrast to the general GIST state case, the MA 167 information for the SID-bound state information is limited to 168 the message associations related to the specific SessionID/ 169 NSLPID tupel. 170 MRS information: The MRS data might include the MRI and 171 information about the upstream and downstream peers, as well as 172 configuration values, such as refresh intervals. 174 NSLP state: 176 It is likely possible to collect some information about the NSLP 177 state corresponding to a particular session ID, if the 178 authorization issue is addressed. However, it should not allow a 179 diagnostics message from any querying node to query state 180 belonging to other sessions or other NSLPs not being the present 181 node (requestor). For NAT/FW NSLP, it may be interesting for a 182 requestor to be able to diagnose the existence of NAT and FW 183 devices (their IP addresses) and if possible, number or detailed 184 information of NAT bindings or firewall entries, without a per- 185 session basis. However, this is subject to authorization 186 decisions in the protocol operation. Also, the QOS NSLP can be 187 diagnosed for various information. 189 In addition, collecting general information such as GIST supporting 190 information (e.g., GIST node IP addresses) or in the case of QoS 191 NSLP, QOSM ID supporting information in the QoS NSLP supporting nodes 192 may be possible. 194 Furthermore, if necessary, one can also calculate the processing 195 delay information in GIST nodes, by putting timestamps to the 196 diagnostics messages when they traverse a GIST node. This simple 197 extension, similar to traceroute, can be added to diagnostics 198 messages as discussed in [6]. 200 The final information we propose to be gathered from NSIS nodes is 201 their support for different NSLPs. For a network administrator it 202 will be helpful to collect which NSLPs are running on a certain node 203 within the domain. This will help finding out whether an NSLP he is 204 diagnosing is still/has been running on said peer. Also, it will be 205 possible to detect still active NSLPs on nodes within the domain 206 which should no longer be running for security reasons. 208 3. Information gathering and data transport options 210 This section will describe conditions and basic usage along with a 211 proposed message format for GIST diagnostics client messages. It 212 will also highlight practical usage for different scenarios. 214 3.1. Basic prerequisites 216 It is desirable that a diagnostics function does not install any new 217 state. However sometimes this is inevitable, for example state in 218 GIST level, especially MRS state even no new MAs will be introduced. 219 It is possible that the diagnostics messages will be transported in a 220 stateless mode and the response messages are directly addressed to 221 the requestor, if it is not necessary to maintain reverse routing 222 information and modify/add results in the reverse direction. On the 223 other hand, if a new MRS needs to be created in querying direction, 224 then it should be removed in the response direction. Therefore, to 225 avoid state creation on NTLP level, diagnostics messages should be 226 kept as small as possible. 228 Diagnostics messages should be limited to fit into a D-mode (e.g., 229 UDP) message in size, thus no larger than 64k and likely limited by 230 the link MTU. 232 For simplicity and easy implementation we will continue NSIS' message 233 object approach. This means that messages created by the diagnostic 234 tool will consist of several objects which themselves could be 235 compiled by adding various other message objects. By this, we also 236 enable easy extensibility for further information gathering of yet 237 unknown NSLPs. 239 We will limit the diagnostic functions towards sysadmins diagnosing 240 withing thei own domain only. 242 Messages by the diagnostics tool consist of one common header 243 followed by a Query object and a list of Hop objects: 245 DIAGNOSTIC-message = 246 Common header, Query object, [Hop object]* 248 The Query object specifies the requested information every GIST node 249 should add. A Hop object is added by every GIST node on the path and 250 contains the requested information. The Hop object itself consists 251 of a Hop-Header and a list of data objects: 253 Hop-object = 254 Hop header 255 [IPv4 address object]* 256 [IPv6 address object]* 257 [General GIST information object] 258 [SID-bound Response object] 259 [NSLP state information object] 260 [Available NSLPs object] 261 [Additional information object] 263 The procedure for the diagnostic tools will be as follows: 264 1. At querying node, compose and send query message with designated 265 destination - the final GIST node along the path 266 2. GIST at querying node forwards message to next GIST node towards 267 the destination 269 3. Intermediate Diagnostic-NSLP-aware GIST nodes add queried 270 information if message is on the downstream direction and forward 271 to next peer 272 4. The destination GIST node adds queried information and forwards 273 the message in the downstream direction 275 The message flow is depicted in Figure 1. 277 +----------+ +----------+ +----------+ 278 | | | | | | 279 |Diagnostic| |Diagnostic| |Diagnostic| 280 | NSLP | | NSLP | | NSLP | 281 | | | | | | 282 +----------+ +----------+ +----------+ 283 1. || /\ 3. /\ || 4. /\ || 284 \/ || || \/ || \/ 285 +--------+2. +--------+ +--------+ +--------+ 286 | |>>>>>>| |>>>>>>| |> .. >| | 287 | GIST | | GIST | | GIST | | GIST | 288 | node | | node | | node | | node | 289 | |<<<<<<| |<<<<<<| |< .. <| | 290 +--------+ +--------+ +--------+ +--------+ 291 >> Upstream query message 292 << Downstream response message 294 Figure 1: Diagnostic NSLP message flow 296 3.1.1. Basic message objects 298 3.1.1.1. Common Header 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Version | Length | Reserved | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 Version : Identifier for diagnostic NSLP 307 Length : Overall message length 309 3.1.1.2. Standard Object Format 311 Each object begins with a fixed header giving the object Type and 312 object Length. This is followed by the object Value, which is a 313 whole number of 32-bit words long. 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 |r|r|r|r| Type |r|r|r|r| Length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 // Value // 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Type 00 : Query object 324 Type 01 : Hop object 325 Type 02 : IPv4 address object 326 Type 03 : IPv6 address object 327 Type 04 : General GIST information object 328 Type 05 : SID-bound Response object 329 Type 06 : NSLP state information object 330 Type 07 : Available NSLPs object 331 Type 08 : Additional information object object 333 3.1.1.3. Hop object 335 The hop object is just a container for the information objects 336 requested in the Query object. 338 3.1.1.4. IPv4 address object 340 Every Hop Object may contain any number of IPv4 address objects. 341 Length: 4 bytes 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | IPv4 address | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 3.1.1.5. IPv6 address object 351 Every Hop Object may contain any number of IPv6 address objects. 352 Length: 16 bytes 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | | 358 | IPv6 address | 359 | | 360 | | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 3.2. NTLP state information 365 As described earlier, we distinguish between general GIST state 366 information and SID-bound state information. When collecting general 367 GIST state information, one has to be careful to limit the amount of 368 gathered information to comply to the basic prerequisites, especially 369 in terms of expected message sizes. For example, when querying for 370 larger sized information the possible maximum amount of nodes the 371 query collects data from and replies it to the querying node, has to 372 be taken into account to not exceed the maximum allowed message size 373 and thereby risk the loss of data. Therefore, mechanisms to prevent 374 overlimits of message size caused by the computation of (informative 375 data size + header sizes) * amount of queried nodes, need to be 376 present. For example, intermediate peers that identify further 377 information to exceed the maximum size could intercept the query 378 process by sending already collected information back to the querying 379 node and trigger a re-querying. The querying node can now start 380 querying information from the intercepting node towards the 381 destination. 383 Hence we propose an extension to the message flow as shown in Figure 384 1 by introducing the possibility for every Diagnostic NSLP to act as 385 a query intercepter: 387 +----------+ +----------+ +-----------+ +----------+ 388 | | | | |Diagnostic | | | 389 |Diagnostic| |Diagnostic| | NSLP | |Diagnostic| 390 | NSLP | | NSLP | | query | | NSLP | 391 | | | | |intercepter| | | 392 +----------+ +----------+ +-----------+ +----------+ 393 1. || /\ 3. /\ || 4. /\ || 5. 7. /\ || 394 6. \/ || || \/ || \/ || \/ 395 +--------+2. +--------+ +--------+ +--------+ 396 | |>>>>>>| |>>>>>>| |> .. >| | 397 | GIST | | GIST | | GIST | | GIST | 398 | node | | node | | node | | node | 399 | |<<<<<<| |<<<<<<| |< .. <| | 400 +--------+ +--------+ +--------+ +--------+ 401 >> Upstream query message 402 << Downstream response message 404 Figure 2: Extended message flow with intercepting node 406 Here we introduce 3 new actions: 407 1. At querying node, compose and send query message with designated 408 destination - the final GIST node along the path 409 2. GIST at querying node forwards message to next GIST node towards 410 the destination 411 3. Intermediate Diagnostic-NSLP-aware GIST nodes add queried 412 information if message is on the downstream direction and forward 413 to next peer 414 4. One peer discovers that adding the requested information would 415 exceed the maximum message size and intercepts the querying 416 process. 417 5. The intercepting node sends the already collected informational 418 data downstream towards the querying node. 419 6. The querying node extracts the stores the data already collected 420 along the path up to the intercepting node. It then sends a new 421 query message directed at the destination node from the 422 intercepting node on to collect data further along the path. 423 7. The destination GIST node adds queried information and forwards 424 the message in the downstream direction 426 3.2.1. General GIST state information 428 This will be discussed in a later version 430 3.2.2. SID-bound state information 432 This will be discussed in a later version 434 3.3. NSLP state information 436 Which information to collect about states linked to a specific SID 437 depends on the NSLP being queried. However, some basic information 438 common to all NSLPs could still be gathered, for example the total 439 amount of states connected to a specific SID. Querying of supported 440 NSLP-IDs on each GIST node should be limited to Administrators only. 442 3.3.1. NSLP state information object 444 NSLP state information object. 445 Length: Variable 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | NSLP ID | Length | Reserved | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 |InformationType| Value | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 : : 455 |InformationType| Value | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 NSLP ID: Identifier for queried NSLP 459 Length : Overall message length 460 InformationType : Identifier for information that is to be queried 461 on GIST nodes up to destination 462 Value : Value of queried information 464 Information Type could be any data queried at a GIST node which could 465 be used for diagnosis. Example: Total amount of states maintained by 466 a QoS NSLP, Value would then contain that amount. When acting as a 467 query message, only the InformationType fields will be present and 468 contain the identifier. Intermediate GIST nodes and the destination 469 GIST node will then enter the values accordingly. This would also 470 allow for querying multiple types of information. 472 GIST nodes not able to provide the requested information enter a 473 value of 0 if they couldn't provide the information due to non 474 availability and -1 if an error occured into the specific value 475 field. 477 3.4. Query available NSLPs 479 This scenario can be expected to be most widely used. Also, it 480 should be the most easiest one to deploy and implement aswell as 481 gather the requested information. The diagnostics NSLP simply 482 queries for other NSLP IDs on the GIST nodes, collects them and adds 483 their values to the RESPONSE object together with the total amount of 484 IDs and finally its IP address. 486 3.4.1. Available NSLPs object 488 Available NSLPs object lists the NSLP IDs supported at the given GIST 489 node. 490 Length: Variable (depends on the number of NSLPs supported on the 491 GIST node) 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Length | Reserved | ID of 1st NSLP | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 |ID of 2nd NSLP | ... 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 : : 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 ... | Id of nth NSLP | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Length : Overall message length 506 ID of Xth NSLP : NSIS ID of NSLP existing and supported by GIST 507 node 509 3.5. Additional information 511 Additional information can be gathered by computing the minimum, 512 maximum and average delay of a roundtrip with values collected by 513 running an instance of the PING Deamon. Other possible data to be 514 queried for can include the software version of GIST, the OS running 515 GIST, amount of known peers and other useful information. 517 4. Security Considerations 519 Authorization and protection of the diagnostics messages seem to be 520 two outstanding issues, among the various issues identified in [7]. 522 On one hand, one may desire that only the state installer can query 523 the session-specific state. For general information diagnostics, 524 measures may be desired for allowing administrators only be able to 525 make the operations across their own domains, or neighboring trusted 526 domains. 528 On the other hand, the diagnostics messages carry senstive 529 information that needs to be integrity protected. Some measures may 530 be utilized such as reusing the secure MAs (if available) between the 531 neigboring GIST nodes, or add NSLP level security mechanisms such as 532 CMS. 534 A future version of this document will add more security relevant 535 considerations. 537 5. Summary and Open Issues 539 We have discussed in this document how diagnostics functions for NSIS 540 implementations as a common NSLP could be designed. Our intention is 541 to keep it as simple and secure as possible. 543 Further possible additions to the diagnostics function could be 544 diagnostics support for tunnelling and mobility devices. 546 A new NSLP ID needs to be defined if a common NSLP for diagnostics 547 functions is devised. 549 6. IANA Considerations 551 A future version of this document will provide details about an IANA 552 consideration. 554 7. Acknowledgments 556 The authors would like to thank Sebastian Willert, Henning Peters, 557 Luis Cordeiro and Bernd Schloer for the discussion and implementation 558 of the early ideas. Moreover, Robert Braden, Scott Bradner, Robert 559 Hancock, John Loughney, Jukka Manner, Andrew McDonald, David Oran and 560 Martin Stiemerling provided valuable comments. 562 8. References 563 8.1. Normative References 565 [1] Manner, J., "NSLP for Quality-of-Service signalling", 566 draft-ietf-nsis-qos-nslp-09 (work in progress), February 2006. 568 [2] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol 569 (NSLP)", draft-ietf-nsis-nslp-natfw-09 (work in progress), 570 February 2006. 572 [3] Schulzrinne, H. and R. Hancock, "GIST: General Internet 573 Signaling Transport", draft-ietf-nsis-ntlp-09 (work in 574 progress), February 2006. 576 8.2. Informative References 578 [4] Terzis, A., Braden, B., Vincent, S., and L. Zhang, "RSVP 579 Diagnostic Messages", RFC 2745, January 2000. 581 [5] Tschofenig, H. and R. Graveman, "RSVP Security Properties", 582 RFC 4230, December 2005. 584 [6] Juchem, I., "A stateless Ping tool for simple tests of GIMPS 585 implementations", draft-juchem-nsis-ping-tool-02 (work in 586 progress), July 2005. 588 [7] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next 589 Steps in Signaling (NSIS)", RFC 4081, June 2005. 591 Authors' Addresses 593 Xiaoming Fu 594 University of Goettingen 595 Institute for Informatics 596 Lotzestr. 16-18 597 Goettingen 37083 598 Germany 600 Email: fu@cs.uni-goettingen.de 602 Ingo Juchem 603 University of Goettingen 604 Institute for Informatics 605 Lotzestr. 16-18 606 Goettingen 37083 607 Germany 609 Email: ijuchem@cs.uni-goettingen.de 611 Christian Dickmann 612 University of Goettingen 613 Institute for Informatics 614 Lotzestr. 16-18 615 Goettingen 37083 616 Germany 618 Email: mail@christian-dickmann.de 620 Hannes Tschofenig 621 Siemens 622 Otto-Hahn-Ring 6 623 Munich, Bayern 81739 624 Germany 626 Email: Hannes.Tschofenig@siemens.com 628 Intellectual Property Statement 630 The IETF takes no position regarding the validity or scope of any 631 Intellectual Property Rights or other rights that might be claimed to 632 pertain to the implementation or use of the technology described in 633 this document or the extent to which any license under such rights 634 might or might not be available; nor does it represent that it has 635 made any independent effort to identify any such rights. Information 636 on the procedures with respect to rights in RFC documents can be 637 found in BCP 78 and BCP 79. 639 Copies of IPR disclosures made to the IETF Secretariat and any 640 assurances of licenses to be made available, or the result of an 641 attempt made to obtain a general license or permission for the use of 642 such proprietary rights by implementers or users of this 643 specification can be obtained from the IETF on-line IPR repository at 644 http://www.ietf.org/ipr. 646 The IETF invites any interested party to bring to its attention any 647 copyrights, patents or patent applications, or other proprietary 648 rights that may cover technology that may be required to implement 649 this standard. Please address the information to the IETF at 650 ietf-ipr@ietf.org. 652 Disclaimer of Validity 654 This document and the information contained herein are provided on an 655 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 656 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 657 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 658 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 659 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 660 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 662 Copyright Statement 664 Copyright (C) The Internet Society (2006). This document is subject 665 to the rights, licenses and restrictions contained in BCP 78, and 666 except as set forth therein, the authors retain all their rights. 668 Acknowledgment 670 Funding for the RFC Editor function is currently provided by the 671 Internet Society.