idnits 2.17.1 draft-ietf-ippm-connectivity-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 109 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 355: '...port-unreachable MUST treat it the sa...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '... Drafts are ...' == Line 12 has weird spacing: '...cuments of t...' == Line 13 has weird spacing: '...ups may also ...' == Line 21 has weird spacing: '...e check the...' == Line 22 has weird spacing: '...listing conta...' == (104 more instances...) -- 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 (November 1998) is 9288 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) == Unused Reference: 'RFC1812' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 384, but no explicit reference was found in the text == Unused Reference: 'RFC2330' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'RFC791' is defined on line 395, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2330 Summary: 12 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Mahdavi, Pittsburgh Supercomputer Center 3 Internet Draft V. Paxson, Lawrence Berkeley National Laboratory 4 Expiration Date: May 1999 November 1998 6 IPPM Metrics for Measuring Connectivity 7 9 1. Status of this Memo 11 This document is an Internet Draft. Internet Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet Drafts as reference 19 material or to cite them other than as ``work in progress''. 21 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 24 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 25 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 27 This memo provides information for the Internet community. This memo 28 does not specify an Internet standard of any kind. Distribution of 29 this memo is unlimited. 31 2. Introduction 33 Connectivity is the basic stuff from which the Internet is made. 34 Therefore, metrics determining whether pairs of hosts (IP addresses) 35 can reach each other must form the base of a measurement suite. We 36 define several such metrics, some of which serve mainly as building 37 blocks for the others. 39 This memo defines a series of metrics for connectivity between a pair 40 of Internet hosts. It builds on notions introduced and discussed in 41 RFC 2330, the IPPM framework document. The reader is assumed to be 42 familiar with that document. 44 The structure of the memo is as follows: 46 ID IPPM Metrics for Measuring Connectivity November 1998 48 + An analytic metric, called Type-P-Instantaneous-Unidirectional- 49 Connectivity, will be introduced to define one-way connectivity at 50 one moment in time. 51 + Using this metric, another analytic metric, called Type-P- 52 Instantaneous-Bidirectional-Connectivity, will be introduced to 53 define two-way connectivity at one moment in time. 54 + Using these metrics, corresponding one- and two-way analytic 55 metrics are defined for connectivity over an interval of time. 56 + Using these metrics, an analytic metric, called Type-P1-P2- 57 Interval-Temporal-Connectivity, will be introduced to define a 58 useful notion of two-way connectivity between two hosts over an 59 interval of time. 60 + Methodologies are then presented and discussed for estimating 61 Type-P1-P2-Interval-Temporal-Connectivity in a variety of 62 settings. 63 Careful definition of Type-P1-P2-Interval-Temporal-Connectivity and 64 the discussion of the metric and the methodologies for estimating it 65 are the two chief contributions of the memo. 67 3. Instantaneous One-way Connectivity 69 3.1. Metric Name: 71 Type-P-Instantaneous-Unidirectional-Connectivity 73 3.2. Metric Parameters: 74 + Src, the IP address of a host 75 + Dst, the IP address of a host 76 + T, a time 78 3.3. Metric Units: 80 Boolean. 82 3.4. Definition: 84 Src has *Type-P-Instantaneous-Unidirectional-Connectivity* to Dst at 85 time T if a type-P packet transmitted from Src to Dst at time T will 86 arrive at Dst. 88 ID IPPM Metrics for Measuring Connectivity November 1998 90 3.5. Discussion: 92 For most applications (e.g., any TCP connection) bidirectional 93 connectivity is considerably more germane than unidirectional 94 connectivity, although unidirectional connectivity can be of interest 95 for some security applications (e.g., testing whether a firewall 96 correctly filters out a "ping of death"). Most applications also 97 require connectivity over an interval, while this metric is 98 instantaneous, though, again, for some security applications 99 instantaneous connectivity remains of interest. Finally, one might 100 not have instantaneous connectivity due to a transient event such as 101 a full queue at a router, even if at nearby instants in time one does 102 have connectivity. These points are addressed below, with this 103 metric serving as a building block. 105 Note also that we have not explicitly defined *when* the packet 106 arrives at Dst. The TTL field in IP packets is meant to limit IP 107 packet lifetimes to 255 seconds (RFC 791). In practice the TTL field 108 can be strictly a hop count (RFC 1812), with most Internet hops being 109 much shorter than one second. This means that most packets will have 110 nowhere near the 255 second lifetime. In principle, however, it is 111 also possible that packets might survive longer than 255 seconds. 112 Consideration of packet lifetimes must be taken into account in 113 attempts to measure the value of this metric. 115 Finally, one might assume that unidirectional connectivity is 116 difficult to measure in the absence of connectivity in the reverse 117 direction. Consider, however, the possibility that a process on 118 Dst's host notes when it receives packets from Src and reports this 119 fact either using an external channel, or later in time when Dst does 120 have connectivity to Src. Such a methodology could reliably measure 121 the unidirectional connectivity defined in this metric. 123 4. Instantaneous Two-way Connectivity 125 4.1. Metric Name: 127 Type-P-Instantaneous-Bidirectional-Connectivity 129 4.2. Metric Parameters: 131 ID IPPM Metrics for Measuring Connectivity November 1998 133 + A1, the IP address of a host 134 + A2, the IP address of a host 135 + T, a time 137 4.3. Metric Units: 139 Boolean. 141 4.4. Definition: 143 Addresses A1 and A2 have *Type-P-Instantaneous-Bidirectional- 144 Connectivity* at time T if address A1 has Type-P-Instantaneous- 145 Unidirectional-Connectivity to address A2 and address A2 has Type-P- 146 Instantaneous-Unidirectional-Connectivity to address A1. 148 4.5. Discussion: 150 An alternative definition would be that A1 and A2 are fully connected 151 if at time T address A1 has instantaneous connectivity to address A2, 152 and at time T+dT address A2 has instantaneous connectivity to A1, 153 where T+dT is when the packet sent from A1 arrives at A2. This 154 definition is more useful for measurement, because the measurement 155 can use a reply from A2 to A1 in order to assess full connectivity. 156 It is a more complex definition, however, because it breaks the 157 symmetry between A1 and A2, and requires a notion of quantifying how 158 long a particular packet from A1 takes to reach A2. We postpone 159 discussion of this distinction until the development of interval- 160 connectivity metrics below. 162 5. One-way Connectivity 164 5.1. Metric Name: 166 Type-P-Interval-Unidirectional-Connectivity 168 5.2. Metric Parameters: 169 + Src, the IP address of a host 171 ID IPPM Metrics for Measuring Connectivity November 1998 173 + Dst, the IP address of a host 174 + T, a time 175 + dT, a duration 176 {Comment: Thus, the closed interval [T, T+dT] denotes a time 177 interval.} 179 5.3. Metric Units: 181 Boolean. 183 5.4. Definition: 185 Address Src has *Type-P-Interval-Unidirectional-Connectivity* to 186 address Dst during the interval [T, T+dT] if for some T' within [T, 187 T+dT] it has Type-P-instantaneous-connectivity to Dst. 189 6. Two-way Connectivity 191 6.1. Metric Name: 193 Type-P-Interval-Bidirectional-Connectivity 195 6.2. Metric Parameters: 196 + A1, the IP address of a host 197 + A2, the IP address of a host 198 + T, a time 199 + dT, a duration 200 {Comment: Thus, the closed interval [T, T+dT] denotes a time 201 interval.} 203 6.3. Metric Units: 205 Boolean. 207 6.4. Definition: 209 Addresses A1 and A2 have *Type-P-Interval-Bidirectional-Connectivity* 210 between them during the interval [T, T+dT] if address A1 has Type-P- 211 Interval-Unidirectional-Connectivity to address A2 during the 212 interval and address A2 has Type-P-Interval-Unidirectional- 213 Connectivity to address A1 during the interval. 215 ID IPPM Metrics for Measuring Connectivity November 1998 217 6.5. Discussion: 219 This metric is not quite what's needed for defining "generally 220 useful" connectivity - that requires the notion that a packet sent 221 from A1 to A2 can elicit a response from A2 that will reach A1. With 222 this definition, it could be that A1 and A2 have full-connectivity 223 but only, for example, at time T1 early enough in the interval [T, 224 T+dT] that A1 and A2 cannot reply to packets sent by the other. This 225 deficiency motivates the next metric. 227 7. Two-way Temporal Connectivity 229 7.1. Metric Name: 231 Type-P1-P2-Interval-Temporal-Connectivity 233 7.2. Metric Parameters: 234 + Src, the IP address of a host 235 + Dst, the IP address of a host 236 + T, a time 237 + dT, a duration 238 {Comment: Thus, the closed interval [T, T+dT] denotes a time 239 interval.} 241 7.3. Metric Units: 243 Boolean. 245 7.4. Definition: 247 Address Src has *Type-P1-P2-Interval-Temporal-Connectivity* to 248 address Dst during the interval [T, T+dT] if there exist times T1 and 249 T2, and time intervals dT1 and dT2, such that: 250 + T1, T1+dT1, T2, T2+dT2 are all in [T, T+dT]. 251 + T1+dT1 <= T2. 252 + At time T1, Src has Type-P1 instantanous connectivity to Dst. 253 + At time T2, Dst has Type-P2 instantanous connectivity to Src. 254 + dT1 is the time taken for a Type-P1 packet sent by Src at time T1 255 to arrive at Dst. 257 ID IPPM Metrics for Measuring Connectivity November 1998 259 + dT2 is the time taken for a Type-P2 packet sent by Dst at time T2 260 to arrive at Src. 262 7.5. Discussion: 264 This metric defines "generally useful" connectivity -- Src can send a 265 packet to Dst that elicits a response. Because many applications 266 utilize different types of packets for forward and reverse traffic, 267 it is possible (and likely) that the desired responses to a Type-P1 268 packet will be of a different type Type-P2. Therefore, in this 269 metric we allow for different types of packets in the forward and 270 reverse directions. 272 7.6. Methodologies: 274 Here we sketch a class of methodologies for estimating Type-P1-P2- 275 Interval-Temporal-Connectivity. It is a class rather than a single 276 methodology because the particulars will depend on the types P1 and 277 P2. 279 7.6.1. Inputs: 280 + Types P1 and P2, addresses A1 and A2, interval [T, T+dT]. 281 + N, the number of packets to send as probes for determining 282 connectivity. 283 + W, the "waiting time", which bounds for how long it is useful to 284 wait for a reply to a packet. 285 Required: W <= 255, dT > W. 287 7.6.2. Recommended values: 289 dT = 60 seconds. 290 W = 10 seconds. 291 N = 20 packets. 293 7.6.3. Algorithm: 295 + Compute N *sending-times* that are randomly, uniformly distributed 296 over [T, T+dT-W]. 298 ID IPPM Metrics for Measuring Connectivity November 1998 300 + At each sending time, transmit from A1 a well-formed packet of 301 type P1 to A2. 302 + Inspect incoming network traffic to A1 to determine if a 303 successful reply is received. The particulars of doing so are 304 dependent on types P1 & P2, discussed below. If any successful 305 reply is received, the value of the measurement is "true". At 306 this point, the measurement can terminate. 307 + If no successful replies are received by time T+dT, the value of 308 the measurement is "false". 310 7.6.4. Discussion: 312 The algorithm is inexact because it does not (and cannot) probe 313 temporal connectivity at every instant in time between [T, T+dT]. 314 The value of N trades off measurement precision against network 315 measurement load. The state-of-the-art in Internet research does not 316 yet offer solid guidance for picking N. The values given above are 317 just guidelines. 319 7.6.5. Specific methodology for TCP: 321 A TCP-port-N1-port-N2 methodology sends TCP SYN packets with source 322 port N1 and dest port N2 at address A2. Network traffic incoming to 323 A1 is interpreted as follows: 324 + A SYN-ack packet from A2 to A1 with the proper acknowledgement 325 fields and ports indicates temporal connectivity. The measurement 326 terminates immediately with a value of "true". {Comment: if, as a 327 side effect of the methodology, a full TCP connection has been 328 established between A1 and A2 -- that is, if A1's TCP stack 329 acknowledges A2's SYN-ack packet, completing the three-way 330 handshake -- then the connection now established between A1 and A2 331 is best torn down using the usual FIN handshake, and not using a 332 RST packet, because RST packets are not reliably delivered. If 333 the three-way handshake is not completed, however, which will 334 occur if the measurement tool on A1 synthesizes its own initial 335 SYN packet rather than going through A1's TCP stack, then A1's TCP 336 stack will automatically terminate the connection in a reliable 337 fashion as A2 continues transmitting the SYN-ack in an attempt to 338 establish the connection. Finally, we note that using A1's TCP 339 stack to conduct the measurement complicates the methodology in 340 that the stack may retransmit the initial SYN packet, altering the 341 number of probe packets sent.} 343 ID IPPM Metrics for Measuring Connectivity November 1998 345 + A RST packet from A2 to A1 with the proper ports indicates 346 temporal connectivity between the addresses (and a *lack* of 347 service connectivity for TCP-port-N1-port-N2 - something that 348 probably should be addressed with another metric). 349 + An ICMP port-unreachable from A2 to A1 indicates temporal 350 connectivity between the addresses (and again a *lack* of service 351 connectivity for TCP-port-N1-port-N2). {Comment: TCP 352 implementations generally do not need to send ICMP port- 353 unreachable messages because a separate mechanism is available 354 (sending a RST). However, RFC 1122 states that a TCP receiving an 355 ICMP port-unreachable MUST treat it the same as the equivalent 356 transport-level mechanism (for TCP, a RST).} 357 + An ICMP host-unreachable or network-unreachable to A1 (not 358 necessarily from A2) with an enclosed IP header matching that sent 359 from A1 to A2 *suggests* a lack of temporal connectivity. If by 360 time T+dT no evidence of temporal connectivity has been gathered, 361 then the receipt of the ICMP can be used as additional information 362 to the measurement value of "false". 364 {Comment: Similar methodologies are needed for ICMP Echo, UDP, etc.} 366 8. Acknowledgments 368 The comments of Guy Almes, Martin Horneffer, Jeff Sedayao, and Sean 369 Shapira are appreciated. 371 9. Security Considerations 373 As noted in RFC 2330, active measurement techniques, such as those 374 defined in this document, can be abused for denial-of-service attacks 375 disguised as legitimate measurement activity. Furthermore, testing 376 for connectivity can be used to probe firewalls and other security 377 mechnisms for weak spots. 379 10. References 381 [RFC1812] 382 F. Baker, "Requirements for IP Version 4 Routers", June 1995. 384 [RFC1122] 385 R. Braden, Editor, "Requirements for Internet Hosts -- Communi- 386 cation Layers," Oct. 1989. 388 [RFC2330] 390 ID IPPM Metrics for Measuring Connectivity November 1998 392 V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, "Framework for 393 IP Performance Metrics", May 1998. 395 [RFC791] 396 J. Postel, "Internet Protocol", September 1981. 398 11. Authors' Addresses 400 Jamshid Mahdavi 401 Pittsburgh Supercomputing Center 402 4400 5th Avenue 403 Pittsburgh, PA 15213 404 USA 406 Vern Paxson 407 MS 50A-3111 408 Lawrence Berkeley National Laboratory 409 University of California 410 Berkeley, CA 94720 411 USA 412 Phone: +1 510/486-7504