idnits 2.17.1 draft-quittek-pcap-ext-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** 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. ** The abstract seems to contain references ([RemPCAP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (17 November 2000) is 8532 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) == Missing Reference: 'RFC2819' is mentioned on line 223, but not defined == Unused Reference: 'RFC2598' is defined on line 549, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-bullard-pcap-00 -- Possible downref: Normative reference to a draft: ref. 'RemPCAP' == Outdated reference: A later version (-16) exists of draft-ietf-diffserv-mib-05 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Quittek 3 NEC Europe Ltd. 4 Expires: May 2001 5 G. Carle 6 GMD FOKUS 8 17 November 2000 10 Remote Packet Capture Extensions 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This memo suggests two extensions of the recommendations for remote 36 packet capture given in [RemPCAP]. The extensions concern the 37 suggested captured packet encapsulation header and the configuration 38 of packet capturing devices. The captured packet encapsulation header 39 is extended by flags indicating simple steps of pre-processing 40 captured packet headers. Most indicated pre-processing actions are 41 merging actions of headers with common properties. For configuration 42 of packet capturing devices, a configuration record is suggested. 44 Table of content 46 1. Introduction 47 2. Packet Merging 48 2.1. Fragment Merge (FM) 49 2.2. TCP Socket merge (TS) 50 2.3. UDP Socket merge (US) 51 2.4. Peer Pair merge (PP) 52 2.5. Source Merge (SM) and Destination Merge (DM) 53 2.6. Source Peer merge (SP) Destination Peer merge (DP) 54 3. Packet (Pre-)Filtering 55 4. Merging Extensions and Extended Captured Packet Encapsulation 56 Header 57 4.1. Actions bit field 58 4.2. Number of merged packets 59 4.3. Total length of all packets 60 4.4. Time Stamp (last) 61 4.5. Filter Identifier 62 5. Packet Capturing Configuration Record 63 5.1. General capturing configuration 64 5.2. Receivers of captured packet data 65 5.3. Filter specifications 66 6. Security Considerations 67 7. References 68 8. Authors' Addresses 70 1. Introduction 72 The recommendations for remote packet capturing given in [RemPCAP] 73 include a captured packet encapsulation header which can be used for 74 transmitting captured packets or portions of those. Usually the 75 portion of the packet that is transmitted contains the IP header, the 76 transport header and parts of the application header. 78 The captured packet encapsulation header was defined assuming that 79 each packet portion will be transmitted separately. Considering the 80 processing power of today's network interfaces, it appears to be 81 appropriate to reflect in a captured packet encapsulation header also 82 possible ways of packet header pre-processing by the capturing 83 device. 85 Particularly merging of packets and filtering of packets are tasks 86 many network interfaces are capable of or - at least- prepared for. 87 For example interfaces with integrated packet classifier or traffic 88 shapers are equipped with sufficient capabilities to perform packet 89 (pre-)filtering and merging of packet headers. The first extension 90 suggested in this memo extends the captured packet encapsulation 91 header by fields indicating what kind of merging (c.f. section 2) or 92 filtering (c.f. section 3) was applied at the packet capturing 93 device. 95 While these merging functions are suitable for activity detection, 96 extended merging functions may collect additional aggregated 97 information for merged packets, such as flow activity time, number of 98 merged packets, data volume of merged packets. This requires the 99 definition of a Flow idle timeout for identification of a last packet 100 of a flow. An extended captured packet encapsulation header is 101 defined for transmitting the additional information (c.f. section 102 4.). 104 The second extension deals with configuring packet capturing devices 105 (c.f. section 5). Certainly, there are ways of configuring them 106 manually via command line interfaces or other means. However, an 107 automated remote configuration of these devices appears to be 108 desirable. This memo recommends a packet capturing configuration 109 record for device configuration covering the configuration of packet 110 merging and of packet filtering. 112 2. Packet Merging 114 For many metering applications merging of packets belonging to the 115 same 'flow' is of interest. (Various types of flow specification 116 appear appropriate.) A package capturing device may already have the 117 abilities to merge packets. These capabilities may vary among 118 different devices. However, it is desirable to exploit the 119 capabilities that are available. 121 The kind of merge required may be different. The following table 122 lists a set of merging actions that appear to be desirable for 123 several applications using packet capturing. 125 +----+------------------------+-------------------------------------+ 126 | FM | Fragment Merge | merge all fragments of the same | 127 | | | original IP packet | 128 +----+------------------------+-------------------------------------+ 129 | TS | TCP Socket merge | merge all packets belonging to the | 130 | | | same TCP socket | 131 +----+------------------------+-------------------------------------+ 132 | US | UDP Socket merge | merge all packets belonging to the | 133 | | | same UDP socket | 134 +----+------------------------+-------------------------------------+ 135 | PP | Peer Pair merge | merge all packets between the same | 136 | | | pair of IP addresses | 137 +----+------------------------+-------------------------------------+ 138 | SM | Source Merge | merge all packets with the same | 139 | | | source IP address and port number | 140 +----+------------------------+-------------------------------------+ 141 | DM | Destination Merge | merge all packets with the same | 142 | | | destination IP address and port | 143 | | | number | 144 +----+------------------------+-------------------------------------+ 145 | SP | Source Peer merge | merge all packets with the same | 146 | | | source IP address | 147 +----+------------------------+-------------------------------------+ 148 | DP | Destination Peer merge | merge all packets with the same | 149 | | | destination IP address | 150 +----+------------------------+-------------------------------------+ 152 Table 1: Kinds of packet merging 154 The suggested extension of the captured packet encapsulation header 155 (described below) signals merging actions applied to packets by 156 references to the actions of this table. Also the suggested packet 157 capturing configuration record uses the listed actions for 158 configuring packet capturing devices. The following subsections 159 describe each merging action. 161 2.1. Fragment Merge (FM) 163 IP packets may be fragmented while they are forwarded. For some 164 application it is required to count only the number of originally 165 sent 'complete' IP packets and to ignore fragmentation. Merging all 166 IP fragments originally belonging to the same IP datagram is one of 167 the merging actions that can be performed by packet capturing devices 168 before they report about captured packets. After the merge, only the 169 fragment with the lowest fragment offset is reported by the capturing 170 device. 172 2.2. TCP Socket merge (TS) 174 Many traffic measurement applications require information not on a 175 per packet base, but on a per flow base. TCP Socket merge denotes the 176 merging of all packets that share the same source IP address, source 177 TCP port, destination IP address and destination TCP port. TCP Socket 178 merging can be uni-directional or bi-directional. In uni-directional 179 mode packets for each direction are merged separately, in bi- 180 directional mode all packets independent of the direction (source to 181 destination or vice versa) are merged before the capturing device 182 reports about them. In any case, the report contains only the first 183 header captured. 185 2.3. UDP Socket merge (US) 187 UDP socket merge is defined analogously to TCP socket merge. The 188 packets to be merged must have common source and destination 189 addresses and port numbers. Packets are merged either in uni- 190 directional mode or in bi-directional mode. 192 2.4. Peer Pair merge (PP) 194 Peer pair merge denotes the merging of all packets sent between a 195 pair of IP addresses. Packets are merged either in uni-directional 196 mode or in bi-directional mode. 198 2.5. Source Merge (SM) and Destination Merge (DM) 200 These actions merge all packets that share the IP address, the 201 transport type, and the port number for the source or for the 202 destination, respectively. Only the first captured packet is 203 reported. 205 2.6. Source Peer merge (SP) Destination Peer merge (DP) 207 These actions are similar to source merge and destination merge, 208 respectively. The only difference is that only the IP addresses are 209 considered when packets are merged. Differences in transport type or 210 protocol numbers are ignored. 212 3. Packet (Pre-)Filtering 214 Many applications requiring packet capturing need only a subset of 215 all packets observed by the capturing device to be captured. For 216 these applications it is desirable to exploit filtering functionality 217 available at the capturing device in order to reduce the amount of 218 data to be exchanged and to increase scalability. A simple packet 219 filter may reduce the number of packets to be reported significantly, 220 before a more advanced filter receives and processes them. 222 Filters can be specified in several ways. For example the the Meter 223 MIB [RFC2720], the RMON MIB [RFC2819], and the DiffServ MIB [DS-MIB] 224 use different filter specifications for IP packets. Some of these 225 specifications may be very long and complex. Because of this, it does 226 not appear to be appropriate for a packet capturing device to add the 227 applied filter specification to the report of a captured packet. 229 However, reporting that a filter was applied when a packet was 230 captured seems to be an important information that should not be 231 omitted. And for specifying what filter has been applied, a filter 232 identifier is a solution, that might provide sufficient information 233 in many cases. 235 It should be noted that the filtering mechanisms available at a 236 packet capturing device are expected to be rather simple and not as 237 powerful as for example the mechanism offered by the Meter MIB. 239 4. Merging Extensions and Extended Captured Packet Encapsulation Header 241 The extended captured packet encapsulation header contains seven 242 additional fields compared to the header suggested in [RemPCAP]. A 243 device reporting captured packets signals applied aggregation actions 244 and filtering actions by setting bits in the first new field. The 245 further fields contain information on details of the applied actions. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Source Identifier | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | ifIndex | Interface Type | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Status | Length | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Sequence Number | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Time Stamp (sec) | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Time Stamp (nsec) | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 |F B T U P S D S D F F| Number of merged packets | 263 |M D S S P M M P P A I| | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Total length of all packets | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Time Stamp (last) (sec) | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Time Stamp (last) (nsec) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Filter Identifier | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | 274 | Captured Packet Data | 275 | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Extended Captured Packet Encapsulation Header Format 280 4.1. Actions bit field 282 The first new field is a 16 bit field with bits specifying applied 283 merge actions and an applied filter action. If fragment merge was 284 applied, this is indicated by a set FM bit. 286 A set Bi-Directional (BD) bit indicates the bi-directional mode for 287 TS, US, and PP. If this bit is not set, uni-directional mode is 288 indicated. in combination with other merge actions the BD bit has not 289 meaning. 291 The next seven bits indicate the merge action applied. Most of them 292 exclude each other. The only combinations of two bits that may be set 293 at the same time are TS and US, SM and DM, SP and DP. Combinations of 294 more than two bits may not be set. 296 The next five bits are unused. The remaining two bits indicate 297 further properties of the reported flow. The the Filter Applied (FA) 298 bit indicates that this packet was captured after applying a filter. 299 The Flow Idle timeout (FI) bit indicates that a timeout was observed 300 for the reported flow, i.e. no packet of this flow has been observed 301 for a period of time longer than a given timeout. 303 4.2. Number of merged packets 305 This 16 bit field indicates the number of packets merged into one. 306 The interpretation of the field depends on the applied merge options: 308 - If the FM bit is set and none of the bits TS, US, PP, BD, SM, 309 DM, SP, and DP is set, then this number indicates the number of 310 fragments that have been merged into one. 312 - If one of the bits TS, US, PP, BD, SM, DM, SP, and DP is set in 313 combination with the FM bit, then the group of all fragments 314 with the same identification field in the IP header is counted 315 as one packet when computing the number of merged packets. 317 - If one of the bits TS, US, PP, BD, SM, DM, SP, and DP is set and 318 the FM bit is not set, then all fragments with the same 319 identification field in the IP header are counted individually 320 for the number of merged packets. 322 4.3. Total length of all packets 324 This 32 bit field indicates the total length of all packets merged 325 into one. 327 4.4. Time Stamp (last) 329 These two 32 bit fields are defined analogously to the Time Stamp 330 fields in the original captured packet encapsulation header. With the 331 extension, the original Time Stamp fields indicate the time, the 332 first of the merged packets was observed. The new Time Stamp (last) 333 fields indicate the time, the last merged packet was observed. 335 4.5. Filter Identifier 337 The last field with a length of 32 bit indicates the filter that was 338 applied when the reported packet was captured. For reasons described 339 in section 3. only an identifier is used to specify the filter. The 340 interpretation of this identifier depends on the capturing device and 341 on the configuration of that device. The identifier is only valid, if 342 the FA bit is set. 344 5. Packet Capturing Configuration Record 346 Packet capturing devices can be configured using the packet capturing 347 configuration record. This record allows to specify which functions 348 for packet merging, packet filtering or merging extensions are 349 applied for specific flows. In the latter case, it is also possible 350 to specify flow idle timeouts and the captured size of a packet. (in 351 cases where the default flow idle timeout or captured size appears 352 not to be appropriate). 354 With the Packet Capturing Configuration Record it can also be 355 specified how captured data is to be transmitted to receivers. So 356 far, there is only one transmission method defined using UDP 357 Encapsulation (UE). Multiple receivers are supported. 359 The packet capturing configuration record contains three sections, of 360 which the second and the third are optional. The first mandatory 361 section specifies a general capturing configuration applied by 362 default to all observed packets. The second section specifies a list 363 of receivers of captured packet data. The third section specifies a 364 list of filters applied to packets before they get captured. 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 |F B T U P S D S D U|#of re-| Captured size of packet | 370 |M D S S P M M P P E|ceivers| | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Number of filters specified | Flow idle timeout | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | IP address of receiver of captured packet data 1 | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | receiver's port number 1 | padding | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | IP address of receiver of captured packet data 2 | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | | 381 . . . 382 | | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Filter Identifier 1 | Transport | 385 | | type 1 | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Source IP address 1 | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Destination IP address 1 | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Source port 1 | Destination port 1 | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | Source address| Dest. address | Source port | Dest. port | 394 | mask 1 mask 1 mask 1 mask 1 | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Flow idle timeout 1 | Captured size of packet 1 | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Filter Identifier 2 | Transport | 399 | | type 2 | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | | 402 . . . 403 | | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Packet Capturing Configuration Record 408 5.1. General capturing configuration 410 The first field of the packet capturing configuration record contains 411 twelve bits. The first nine bits (FM, BD, TS, US, PP, SM, DM, SP, and 412 DP) specify merging actions the capturing device is requested to 413 perform on all observed packets. The next two bits are unused, so 414 far. 416 The last bit of this field (UE) indicates (if set) that UDP 417 encapsulation is to be used for transmitting captured packet data. A 418 UDP packet used for this purpose must contain a sequence of 419 encapsulated captured packets according to the extended captured 420 packet encapsulation headers format. 422 The next 4 bit field is to be interpreted as a positive integer 423 number specifying the number of receivers to which reports on 424 captured packet information are to be sent. The receivers are 425 specified in the second section. If the receiver(s) are already 426 specified by other means, the number should be set to zero. 428 The next 16 bit field specifies the minimal (positive) number of 429 bytes to be captured of a packet. this captured size applies to 430 packet data not belonging to the transport layer or lower layers. So, 431 if the captured size is set to zero, still the IP and transport 432 header (TCP, UDP, ICMP, or IGMP) are reported. If the capturing 433 device is not able to interpret transport layer information, a 434 conservative estimation of the captured size has to be made which 435 will ensure, that the requested parts of the packets are always 436 captured. 438 The next 16 bit field specifies the (positive) number of filters 439 specified in the third section of the capturing configuration record. 440 This number may be zero, specifying, that all observed packets are to 441 be reported. If it is non-zero, then the capturing device is 442 requested to report only on packets which have passed one of the 443 filters. 445 The last field of the first section of the packet capturing 446 configuration record specifies the default flow idle timeout of 447 filtered packets. This 16 bit is to be interpreted an a non-negative 448 number of seconds. If for any of the specified filters no packets has 449 been observed for this number of seconds after the last observed 450 packet, then the flow specified by this filter is assumed to be idle 451 and a report on this flow is to be sent. The default timeout may be 452 overwritten by the individual filter specifications in the third 453 section of the packet capturing configuration record. 455 5.2. Receivers of captured packet data 457 The second section of the packet capturing configuration record 458 contains an optionally empty list of receivers of captured packet 459 data. Each item of the list has a size of 64 bit with the first 32 460 bit specifying the receivers IPv4 address and the following 16 bit 461 specifying the receivers port number. The remaining 16 bits are 462 unused. 464 5.3. Filter specifications 466 The third section of the packet capturing configuration record 467 contains an optionally empty list of packet filters. An item of this 468 list specifies a filter and sets two options of processing filtered 469 data. 471 The first 24 bit field serves as filter identifier. The following 472 nine fields identify the packets to be filtered. The fields are 474 - Transport type (8 bit) 475 - Source IP address 476 - Destination IP address 477 - Source port number 478 - Destination port number 479 - Source address mask 480 - Destination address mask 481 - Source port number mask 482 - Destination port number mask 484 The masks for IP addresses and port numbers specify how many of the 485 most relevant bits of the address or mask must be matched by a packet 486 in order to pass the filter. With an address mask value of 0, any 487 address or port number matches; with a mask value of 32, an IP 488 address must be matched exactly. The transport type specifies a value 489 to be matched by the protocol field in the IPv4 header. If it is of 490 value 0, then any transport type is matched. 492 There are two additional fields in the filter specification 493 requesting special processing of packets passing the filter. The flow 494 idle timeout overwrites the default timeout specified in the first 495 section of the packet capturing configuration record. Similarly, the 496 captured size of packets overwrites the corresponding default value 497 for the particular filter. 499 6. Security Considerations 501 Remote packet capturing may cause security threats such as 502 unauthorized access, modification or disclosure of remotely captured 503 packets [RemPCAP]. Protecting privacy of captured data that is being 504 transmitted from the remote capturing node to an authorized entity 505 against listening third parties may be supported by protections 506 through IPSec [RemPCAP]. More important is protecting privacy of 507 captured data against unauthorized initiators of capturing 508 instructions. 510 Similar to restricting access to packet capturing methods at a local 511 node to privileged users, initiation of remote packet capturing 512 methods should be subject to policy control ("is the initiator 513 authorized to perform the remote packet capturing capability"). 515 For certain scenarios such as intra-domain authorization control, 516 SNMPv3 appears adequate. For other scenarios such as third party 517 measurement or accounting services involving inter-domain 518 authorization control, a AAA protocol and AAA servers may be 519 necessary. 521 Simple authorization schemes may distinguish between two user classes 522 (authorized or non-authorized). Complex authorization schemes may 523 require that remote packet capturing requests are subject to policy- 524 based authorization control. Complex authorization control may 525 include fine grain authorization policies, such as which user is 526 allowed to capture which part of the packet (which attributes) 527 depending on flow specifications. For example, authorization policies 528 may specify that the user class 'administrator' may capture remotely 529 within their own domain without restrictions, while the same user 530 class may remotely capture at other domains only packets with source 531 or destination IP addresses of specific networks (typically those 532 belonging to their domain). Authorization policies may also specify 533 that unprivileged users may capture remotely only packets with their 534 source or destination address. 536 Another security issue is the transmission of captured packets. Since 537 they might contain the complete information as the original packet, 538 the security level applied to this transmission must match the 539 security level of the original transmission. 541 7. References 543 [RemPCAP] C. Bullard, "Remote Packet Capture", work in progress, 544 draft-bullard-pcap-00.txt, November 2000. 546 [RFC2720] N. Brownlee, "Traffic Flow Measurement: Meter MIB", 547 RFC 2720, October 1999. 549 [RFC2598] S. Waldbusser, "Remote Network Monitoring Management 550 Information Base", RFC 2819, May 2000. 552 [DS-MIB] F. Baker, K. Chan, A. Smith, "Management Information Base 553 for the Differentiated Services Architecture", work in 554 progress, draft-ietf-diffserv-mib-05.txt, November 2000. 556 8. Authors' Addresses 558 Juergen Quittek 559 NEC Europe Ltd. 560 C&C Research Laboratories 561 Adenauerplatz 6 562 69115 Heidelberg 563 Germany 565 Phone: +49 6221 90511-15 566 EMail: quittek@ccrle.nec.de 568 Georg Carle 569 GMD FOKUS 570 Kaiserin-Augusta-Allee 31 571 10589 Berlin 572 Germany 574 Phone: +49 30 3463 7149 575 Email: carle@fokus.gmd.de