idnits 2.17.1 draft-irtf-nmrg-location-ipfix-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2016) is 2729 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3917' is mentioned on line 268, but not defined == Missing Reference: 'RFC5101' is mentioned on line 377, but not defined ** Obsolete undefined reference: RFC 5101 (Obsoleted by RFC 7011) == Missing Reference: 'GEOSHAPE' is mentioned on line 464, but not defined == Missing Reference: 'WGS84' is mentioned on line 466, but not defined == Missing Reference: 'GeoSHAPE' is mentioned on line 574, but not defined -- Looks like a reference, but probably isn't: '1' on line 818 -- Looks like a reference, but probably isn't: '4' on line 809 -- Looks like a reference, but probably isn't: '2' on line 813 -- Looks like a reference, but probably isn't: '8' on line 815 == Missing Reference: '0XFFFF' is mentioned on line 810, but not defined -- Looks like a reference, but probably isn't: '16' on line 701 == Missing Reference: '0xFFFF' is mentioned on line 755, but not defined == Unused Reference: 'RFC5513' is defined on line 989, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Management Research Group O. Festor 3 Internet-Draft Inria 4 Intended Status: Informational A. Lahmadi 5 Expires: May 3, 2017 University of Lorraine - LORIA 6 R. Hofstede 7 A. Pras 8 University of Twente 9 October 30, 2016 11 Extending IP Flow-Based Network Monitoring with Location Information 12 draft-irtf-nmrg-location-ipfix-07 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 3, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Abstract 50 IP Flow-based monitoring lacks a mechanism to associate measured IP 51 Flow information with the geographic location of the device where the 52 IP Flows have been observed. This document defines a set of 53 guidelines and best practices to extend IP Flow monitoring protocols 54 with location information of the device (both fixed and mobile) that 55 acts as an IP Flow metering process. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Relationships with IPFIX and GEOPRIV . . . . . . . . . . . . . 4 63 3. Location Information specifications . . . . . . . . . . . . . . 5 64 3.1. Geospatial Location Information . . . . . . . . . . . . . . 5 65 3.2. Civic Location Information . . . . . . . . . . . . . . . . 5 66 4. Extending Metering Processes with Location Information . . . . 6 67 4.1 Applicability . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.2 Enabling Location Extensions . . . . . . . . . . . . . . . . 7 69 4.3 Flow Expiration Management . . . . . . . . . . . . . . . . . 8 70 4.4 The Collecting Process's Side . . . . . . . . . . . . . . . 8 71 5. Security and Privacy Considerations . . . . . . . . . . . . . . 9 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 73 6.1 Location method numeric values . . . . . . . . . . . . . . . 9 74 6.2 Location Information Elements . . . . . . . . . . . . . . . 10 75 Appendix A. IPFIX Location Information Elements . . . . . . . . . 11 76 A.1. geospatialLocationCRSCode . . . . . . . . . . . . . . . . . 11 77 A.2. geospatialLocationLat . . . . . . . . . . . . . . . . . . . 11 78 A.3. geospatialLocationLng . . . . . . . . . . . . . . . . . . . 11 79 A.4. geospatialLocationAlt . . . . . . . . . . . . . . . . . . . 11 80 A.5. geospatialLocationRadius . . . . . . . . . . . . . . . . . 12 81 A.6. civicLocationType . . . . . . . . . . . . . . . . . . . . . 12 82 A.7. civicLocationValue . . . . . . . . . . . . . . . . . . . . 12 83 A.8. locationMethod . . . . . . . . . . . . . . . . . . . . . . 12 84 A.9. locationTime . . . . . . . . . . . . . . . . . . . . . . . 13 85 A.10. deviceId . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 Appendix B. Recommended IPFIX Templates for Location Export . . . 14 87 B.1. Geospatial Point Location Template . . . . . . . . . . . . 14 88 B.2. Geospatial Circle Location Template . . . . . . . . . . . . 15 89 B.3. Geospatial List Template . . . . . . . . . . . . . . . . . 16 90 B.4. Civic Location Template . . . . . . . . . . . . . . . . . . 17 91 B.5. Compound Location Template . . . . . . . . . . . . . . . . 19 92 Appendix C. Example Implementation . . . . . . . . . . . . . . . . 21 93 Normative References . . . . . . . . . . . . . . . . . . . . . . . 22 94 Informative References . . . . . . . . . . . . . . . . . . . . . . 23 95 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 98 1. Introduction 100 The importance of geographic location information on the Internet is 101 growing rapidly. It can be used for business advertisements, 102 admission control and security analysis, for example. Most mobile 103 devices, such as smart phones, tablets and sensors, have capabilities 104 for determining and exposing their geographic location. Besides that, 105 they are accountable for an increasing share of the overall network 106 traffic. In contrast to fixed devices, which usually have their 107 physical location configured in a static manner, mobile devices can 108 exploit several location systems for obtaining their location. This 109 type of information is already used by a wide range of applications 110 and services, such as navigation systems and friend finder services. 111 Relating the location information of a device to this network traffic 112 can be beneficial to many network management and measurement 113 applications, including traffic profiling, anomaly detection and 114 provider-independent network measurements. Hence, exporting location 115 information associated to traffic Flows is desirable in various 116 situations. 118 Several IP Flow-based monitoring protocols such as the IPFIX protocol 119 [RFC7011] have been designed for the purpose of exporting IP traffic 120 Flows based on Information Elements. This document defines a set of 121 guidelines that provide a means for Metering Processes to encapsulate 122 location information within exported Flows. This will be done by 123 relying on existing location information formats, as they have been 124 developed in other standardization areas for encoding civic 125 locations, geographic coordinates, etc. Several examples including 126 the required set of Information Elements and templates for the IPFIX 127 protocol are given that are suitable for encapsulating pre-existing 128 location information data. 130 1.1. Motivation 132 A typical IP Flow Metering Process is used for aggregating IP traffic 133 and related measurement data into Flow Records at a fixed Observation 134 Point. After expiration, Flow Records are sent to a Flow Collector 135 for storage and analysis. The collected information is typically 136 represented in a purely time-based manner, which means that Flow 137 Records provide an aggregated view on network traffic over time. 138 However, when Metering Processes are running on devices with a 139 (frequently) changing physical location, data analysis applications 140 may need to be aware of these movements since they are likely to 141 affect the behavior of the network in terms of routing, throughput, 142 etc. An example scenario is a virtualized environment, where virtual 143 machines change location during migration from one server to another, 144 or even between data centers. Thus, a location-aware metering process 145 will be able to associate their Flows to their current locations. 147 In fact, we are not dealing anymore with Flows associated to a fixed 148 Observation Point, but with a multitude of sub-Flows for which the 149 Observation Point locations have to be reported. To facilitate this, 150 location information needs to be obtained and processed by the 151 Metering Process in an IP Flow Exporter. In the end, it will be 152 beneficial when network management applications are able to relate 153 service quality parameters to location changes, instead of assuming a 154 single location for all observed parameters. 156 1.2. Terminology 158 This document relies on on the definitions of IP The key words 159 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 160 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 161 are to be interpreted as described in [RFC2119]. 163 2. Relationships with IPFIX and GEOPRIV 165 The IPFIX protocol [RFC7011] and its information model [RFC7012] are 166 the IETF standards for IP Flow-based network monitoring, developed by 167 the IPFIX working group to transfer IP flow data from exporters to 168 collectors. In this document, we rely on the IPFIX terminology and 169 its information model to illustrate how to export location 170 information of a Metering Process to Collecting Process. Within the 171 IPFIX architecture as defined in [RFC5470], in this document we are 172 providing guidelines for developers to extend Metering Processes with 173 capabilities to include location information in data records to be 174 passed to an Exporting Process before being sent to a Collecting 175 Process. 177 Associating geographic location information with network traffic on 178 the Internet has been addressed by the GEOPRIV working group. There, 179 a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option 180 containing civic address information has been specified in [RFC4776]. 181 A similar option for geospatial information has been defined in 182 [RFC6225]. The group has also defined a set of requirements to be 183 respected when collecting and using Location Objects related to a 184 specific user [RFC3693]. These requirements include usage policies 185 and privacy preferences associated to the Location Object as 186 expressed by a user. All the security and privacy requirements 187 defined in [RFC3693] concern location data collection, and usage MAY 188 be applied to the IPFIX protocol when conveying location information. 189 The GEOPRIV working group has extended the XML-based Presence 190 Information Data Format in [RFC5491], to allow the encapsulation of 191 location information within a presence document. 193 3. Location Information specifications 195 The location of a device can generally be defined in two ways, namely 196 by geospatial location coordinates and civic location information. 197 Geospatial location coordinates are made up of latitude, longitude 198 and altitude coordinates, while civic location information 199 encompasses abstract notions of a location, such as "in the kitchen", 200 "in Bakerstreet" or "in a train approaching Nancy, France". The usage 201 of these two types of location representations are addressed by the 202 GEOPRIV group in [RFC5491] and [RFC5139], respectively. This document 203 assumes that devices use one or more existing mechanisms for the 204 purpose of retrieving location information and therefore does not 205 define any new mechanisms for location retrieval. 207 3.1. Geospatial Location Information 209 To obtain geospatial location information, one needs to rely on a 210 numeric coordinate system. Such systems provide location information 211 either in two dimensions (latitude and longitude) or three dimensions 212 (latitude, longitude and altitude). Relying on a single point of 213 location is normally not considered sufficient, since an area or 214 volume of uncertainty SHALL be specified. In theory, this area or 215 volume represents a coverage in which the device has a high 216 probability of being found, and the point is the centroid for the 217 area or volume. In [GeoShape] a set of geometric areas and volumes 218 has been specified to define a location with uncertainty. A standard 219 set of Coordinate Reference Systems (CRS) and units of measure are 220 also specified in [GeoShape]. Implementations MUST specify distances 221 and heights in meters as defined in EPSG 9001. Angular measures MUST 222 be specified using degrees as identified by the EPSG 9102 code. The 223 values of EPSG codes can be resolved by using the CRS Registry 224 Service operated by the Oil and Gas Producers Association [OGP]. 226 3.2. Civic Location Information 228 In contrast to geospatial location information, which relies on 229 numeric data formats, the civic location format conveys pure textual 230 information. It is applicable to device locations in buildings, for 231 example. It MAY be a civic address closely related to a postal 232 address, commonly used by local postal services for delivering mail. 233 It MAY also be some approximated information, such as "living room", 234 "Office 123 in Building 2". The civic location information format has 235 been addressed in [RFC4776], where a set of parameters are provided 236 to describe civic locations. In contrast to geospatial location 237 information, which is the geospatial location of the device as a set 238 of latitude, longitude and altitude coordinates represented by a CRS, 239 civic location information can often be interpreted even if 240 incomplete. For example, while geospatial information is not 241 available inside buildings, civic location information can still 242 provide an estimation of a device's location. 244 4. Extending Metering Processes with Location Information 246 This section specifies how to carry the location information of the 247 device acting as an IP Flow Exporter from the Metering Process to the 248 Collecting Process, to associate the IP Flow information with the 249 location where the flows are measured. The provided specifications 250 SHALL be used by developers to extend a Metering Process for 251 constructing and sending template and data records including location 252 information to a Collecting Process. 254 4.1 Applicability 256 Extending Metering Processes to include location information in data 257 records with respect to a certain template is applicable to cases 258 where management applications require knowing the location of the 259 device acting as an IP Flow Exporter. A typical example is a mobile 260 device changing its location while exporting IP Flow records. This 261 method requires that the Metering Process is able to obtain location 262 information of the device using one or several localization methods 263 (GPS, Network, Cell, DHPCP, etc.), as defined in section 6. 265 Associating location information with measured IP Flow information is 266 an interesting feature for several network management applications 267 (e.g., accounting, traffic profiling, traffic engineering, QoS 268 monitoring, attack/intrusion detection) as specified in [RFC3917]. 269 Location data records provide space dimension to these applications, 270 in addition to the traditional time and volume dimensions provided by 271 IP Flow measurements. Currently, usage-based accounting for IP 272 services relies on time or volume. Besides that, accounting can be 273 performed per location when enabling location information in Metering 274 Processes. For the case of traffic profiling, providing the location 275 of traffic measurements is useful for network planning, dimensioning 276 activities and traffic engineering methods, for example. Typically, 277 the traffic distribution is characterized by using parameters of 278 flows in a specific location. Associating Flow information with their 279 measurement geographic locations will also enable security 280 applications to detect anomalous activities. In the case of mobile 281 devices, the characterization of communication patterns using only 282 time and volume is not enough to detect unusual location-related 283 communication patterns. For example, a mobile device has a specific 284 communication pattern at each location and when the location changes 285 the communication pattern changes also. If the device is attacked the 286 communication pattern in respect with the device location is unusual 287 that will be easily detected by the security monitoring application. 288 However, this unusual communication pattern over device locations 289 becomes usual over time since it has been observed before. QoS 290 monitoring applications will also benefit from the availability of 291 location information provided by the Metering Process since it will 292 allow them correlating quality parameters of IP Flows with respect to 293 their measurement location. Thus, fine-grained QoS parameters can be 294 validated and analyzed. For example, a QoS monitoring application 295 will be able to correlate IP Flow, their delays and their locations. 297 4.2 Enabling Location Extensions 299 Before enabling location extensions in data records, the Metering 300 Process SHOULD check if a localization method that provides location 301 information is available on the device. The available location 302 information MUST describe a discrete location defined as a place, 303 point or area in which a Metering Process (i.e., IPFIX Flow Exporter) 304 can be found. In situations where a discrete location can be 305 described in multiple ways, each location SHOULD be described by 306 means of a separate Template following the terminology specified in 307 [RFC7012]. A compound Template containing a subTemplateMultiList 308 field as specified in [RFC6313] SHOULD be used in which each top- 309 level element corresponds to a different location Template. For 310 example, the location of a device being at the fifth floor of a 311 particular building can be described using both a geospatial point 312 (the geographic location of the building) and civic information 313 (fifth floor of a building). Exporting more than one location in a 314 Flow Record MUST only be done if the different location descriptions 315 refer to different places. Each time a different type of location 316 data is available to the Metering Process and needed to be sent, the 317 Flow Exporter MUST send the template of the new location format to 318 the Collecting Process. 320 When several localization methods are available on the device, the 321 Metering Process SHALL select one or several among them. If the 322 available methods provide the same type of location information, it 323 selects only a single method. The selected method is the one with the 324 highest accuracy. According to the accuracy of the method, the 325 Metering Process MUST use the appropriate template and the 326 Information Elements from the set of recommended templates and 327 Information Elements specified in Appendixes A and B. We have to note 328 that other criteria MAY be used to select the localization method. 329 For example, in a mobile device where saving energy is important (due 330 to power constraints, for example), the Metering Process MAY select 331 the less power-consuming method. Specifically, a network-based method 332 is typically less power-consuming than a GPS-based localization 333 method. Configuration options MAY also be available on the Metering 334 Process to configure the location method to be used according to the 335 requirements of the management application. 337 When one or several localization methods are selected and activated, 338 the Metering process is able to include location information in data 339 records. When an IP Flow is observed by the Metering Process, 340 location information is derived and included in a data record using 341 an appropriate template that SHOULD be sent to the Collecting Process 342 before sending the location data records. The Metering process should 343 be configured to associate a single or multiple location information 344 to each observed IP Flow. 346 A single location information is derived by the Metering Process 347 either at the time of the first observed packet of the IP Flow or at 348 the time of the last observed packet of the IP Flow. Then, a location 349 data record containing a single location information is built and 350 passed to the Exporting Process. Multiple location information are 351 derived by the Metering Process during the time interval of the 352 observation of the IP Flow. The multiple location information MAY be 353 derived at different time scales. Metering Processes MAY associate 354 two location information, one at the starting time of the observed 355 Flow and the second at the ending time of the Flow. It MAY also 356 sample several information location to be associated with the 357 observed IP Flow. 359 4.3 Flow Expiration Management 361 With the current IPFIX specifications, the Metering Process expires 362 active Flows under several conditions as described in Section 5.1.1 363 of [RFC5470]. When the Metering Process enables location information 364 to be associated to observed IP flows and according to the management 365 application requirements, it MAY consider location or distance 366 information for determining whether a flow has to be expired. For 367 example, a Metering Process MAY expire Flows when the device changes 368 its location. For long-running Flows, the Metering Process may use a 369 distance-based expiration policy, such as expiring a Flow upon a 370 configured distance value in meters. In case location information 371 becomes unavailable on the device, the Metering Process SHOULD expire 372 all running Flows to be able to resend the set of templates as 373 described in Section 4.4. 375 4.4 The Collecting Process's Side 377 As specified in [RFC5101], the Exporting Process SHOULD transmit the 378 required set of templates specific to location information in advance 379 to the Collecting Process, before sending any data records including 380 location data. When the Metering Process is not able to access a 381 localization method or no method is available to obtain such 382 information, it MUST stop resending to the Collection Process 383 location related templates. 385 5. Security and Privacy Considerations 387 This document proposes a set of Information Elements and guidelines 388 for exporting location information using the IPFIX protocol. We 389 recognize the privacy sensitivity of exporting such information and 390 advocate the use of measures to protect individual's privacy. Several 391 documents have addressed security and privacy in the context of the 392 Internet in general and IPFIX in particular. First, the use of 393 location information has been discussed in "GeoPriv Requirements" 394 [RFC3693], while threats facing protocols that carry location 395 information are detailed in [RFC3694]. Second, when carrying location 396 information in IPFIX Information Elements, all Messages exchanged 397 between Exporting and Collecting Processes SHOULD be signed and 398 encrypted using Transport Layer Security (TLS) or Datagram Transport 399 Layer Security (DTLS) protocols, as specified in [RFC7011]. Another 400 approach is the use of a secure, underlying communication channel for 401 transporting IPFIX Messages in case the aforementioned transports are 402 unavailable. Third, support for Flow Record anonymization, as 403 expressed in [RFC6235], is strongly recommended, since the 404 dissemination of Flow Records including location information raises 405 greater privacy issues than the dissemination of regular Flow 406 Records. 408 Preserving the privacy of users SHOULD be addressed by applications 409 using collected monitoring data. We note that collecting and 410 exporting location information associated with information that is 411 able to identify individual by means of their IP addresses, may be 412 illegal or require special clearance in certain jurisdictions. 414 6. IANA Considerations 416 This document specifies several new IPFIX Information Elements and 417 types that need to be registered with IANA. 419 6.1 Location method numeric values 421 This document requests that the IANA adds a new column to its 422 registry for location 'method' tokens defined in [RFC4119] (Section 423 6.1), to facilitate the association of numeric values to these 424 'method' tokens. The numeric values are used by the Information 425 Element 'localtionMethod', as specified in Section A.8 of this 426 document. The numeric values of the registered 'method' tokens are 427 attributed with the IANA on a next available integer basis. An 428 example of registered 'method' tokens and their provisional numeric 429 values is provided below. 431 +--------+--------------+----------------------------------------+ 432 | Number | Method | Description | 433 +--------+--------------+----------------------------------------+ 434 |0 | GPS | Global Positioning System | 435 |1 | A-GPS | GPS with assistance | 436 |2 | Manual | Entered manually by a user | 437 |3 | DHCP | Provided by DHCP | 438 |4 | Triangulation| Triangulated from time-of-arrival, | 439 | | | signal strength or similar measurement | 440 |5 | Cell | Location of the cellular radio antenna | 441 |6 | 802.11 | IEEE 802.11 access point location | 442 +--------+--------------+----------------------------------------+ 444 6.2 Location Information Elements 446 This document requests that the IANA registers the set of Information 447 elements listed in Appendix A in the IANA IPFIX Information Element 448 registry. Registrations of these new Information Elements MUST be 449 reviewed by a designated group of experts (IE-DOCTORS), appointed by the 450 IESG, as indicated in [RFC7013]. 452 Appendix A. IPFIX Location Information Elements 454 This appendix contains a set of IPFIX Information Elements that can be 455 used for exporting location-related information of a Metering Process. 456 They SHALL be used for exporting geospatial and civic location, together 457 with IPFIX Information Elements already defined in [RFC7012] for 458 exporting IP traffic Flows. 460 A.1. geospatialLocationCRSCode 462 Description: Denotes the Coordinate Reference System (CRS) codes 463 according to which the location coordinates are organized and 464 related to the real world, as specified in [GEOSHAPE]. In this 465 document we mandate the use of the World Geodetic System 1984 466 (WGS84) [WGS84] coordinate reference system and the usage of the 467 European petroleum survey group (EPSG) code 4326 for two- 468 dimensional (2D) shape representations and EPSG 4979 for three- 469 dimensional (3D) volume representations. 471 Data Type: unsigned16 472 Data Type Semantics: identifier 473 PEN (provisional): 12559 (Inria) 474 ElementId: 401 476 A.2. geospatialLocationLat 478 Description: Denotes the coordinate information value of the 479 latitude. 481 Data Type: float64 482 PEN (provisional): 12559 (Inria) 483 ElementId (provisional): 402 485 A.3. geospatialLocationLng 487 Description: Denotes the coordinate information value of the 488 longitude. 490 Data Type: float64 491 PEN (provisional): 12559 (Inria) 492 ElementId (provisional): 403 494 A.4. geospatialLocationAlt 496 Description: Denotes the coordinate information value of the 497 altitude. 499 Data Type: float64 500 PEN (provisional): 12559 (Inria) 501 ElementId (provisional): 404 503 A.5. geospatialLocationRadius 505 Description: Denotes a radius value (in meters) of a location 506 described using a circular area in a two-dimensional CRS or 507 a sphere shape in a three-dimensional CRS. 509 Data Type: float32 510 Data Type Semantics: quantity 511 PEN (provisional): 12559 (Inria) 512 ElementId (provisional): 405 514 A.6. civicLocationType 516 Description: Denotes the civic location information type as 517 specified in [RFC4776]. 519 Data Type: unsigned8 520 PEN (provisional): 12559 (Inria) 521 ElementId (provisional): 406 523 A.7. civicLocationValue 525 Description: Denotes a civic location information element that MUST 526 be encoded as a UTF-8 string. The location information MAY be a 527 civic address as specified in [RFC4776] or information on 528 proximity to known objects. 530 Data Type: string 531 PEN (provisional): 12559 (Inria) 532 ElementId (provisional): 407 534 A.8. locationMethod 536 Description: Denotes the way in which the location information has 537 been obtained. The locationMethod sub-registry is defined in 538 Section 6.1. 540 Data Type: unsigned8 541 Data Type Semantics: identifier 542 PEN (provisional): 12559 (Inria) 543 ElementId (provisional): 408 545 A.9. locationTime 547 Description: Denotes the time when the location information is 548 obtained on a device acting as an IPFIX Flow Exporter. The time 549 is expressed in seconds since January 1, 1970, 00:00:00 UTC. 551 Data Type: dateTimeSeconds 552 Data Type Semantics: quantity 553 PEN (provisional): 12559 (Inria) 554 ElementId (provisional): 409 556 A.10. deviceId 558 Description: Denotes an identifier of a physical device acting as an 559 IPFIX Flow Exporter. The Exporting Process uses this identifier 560 to uniquely identify the device where Flows were metered. The 561 identifier is unique per device. This Information Element can 562 be used when an IPFIX Flow Exporter is behind a NAT. 564 Data Type: unsigned64 565 Data Type Semantics: identifier 566 PEN (provisional): 12559 (Inria) 567 ElementId (provisional): 410 569 Appendix B. Recommended IPFIX Templates for Location Export 571 This appendix contains a set of recommended IPFIX Templates for 572 exporting geospatial and civic location information. The geospatial 573 templates are related to a point, circle or area shapes. The 574 definition and usage of the shapes is covered in [GeoSHAPE]. Civic 575 locations can be exported using a Template containing a 576 subTemplateList [RFC6313], where each element of the list corresponds 577 to a Template. 579 B.1. Geospatial Point Location Template 581 The point shape is the simplest form of a geospatial location, which 582 SHOULD be used when there is no known uncertainty. The following 583 Template is defined for exporting a 2D geospatial point location: 585 0 1 2 3 586 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 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Set ID = 2 | Length = 28 | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Template ID = 300 | Field Count = 2 | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | locationMethod = 408 | Field Length = 1 | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | locationTime = 409 | Field Length = 4 | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | geospatialLocationCRSCode=401 | Field Length = 2 | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | geospatialLocationLat = 402 | Field Length = 8 | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | geospatialLocationLng = 403 | Field Length = 8 | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 Figure 1: Template for exporting a 2D point-based geospatial location 605 For illustration, the following presents an example Data Record to 606 export a 2D geospatial point location: 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Set ID = 300 | Length = 28 | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | locMethod = 3 | locationTime = 1234555555 | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | ... octet 4 |geospatialLocationCRSCode=4326 |geospatial ... | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | ... LocationLat = 48.690855 | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | ... octet 6 - 8 |geospatial ... | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | LocationLng = 6.172851 | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | ... octet 6 - 8 | Padding (opt) | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 Figure 2: Data Record of a geospatial 2D point location 628 B.2. Geospatial Circle Location Template 630 The circle Template is suitable for exporting the location of a flow 631 observed within a circle shape where its center is represented using 632 a geospatial point position and its radius represents the 633 uncertainty. 635 Template Record for Geospatial Circle (ID = 301) 636 | locationMethod(408)[1] 637 | locationTime(409)[4] 638 | geospatialLocationCRSCode(401)[2] 639 | geospatialLocationRadius(405)[4] 640 | geospatialLocationLat(402)[8] 641 | geospatialLocationLng(403)[8] 643 Figure 3: Template for exporting a circle-based geospatial location 645 The following presents an example of a Data Record carrying a circle- 646 based geospatial location: 648 0 1 2 3 649 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Set ID = 301 | Length = 32 | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | locMethod = 3 | locationTime = 1234555555 | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | ... octet 4 |geospatialLocationCRSCode=4326 | geospatial ...| 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | ... LocationRadius = 850.24 | geospatial ...| 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | ... LocationPosLat = | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | 42.5463 | geospatial ...| 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | ... LocationLng = | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | -73.2512 | Padding (opt) | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 Figure 4: Data Record of a circle-based geospatial location 670 B.3. Geospatial List Template 672 The list locations Template is suitable for exporting a variable- 673 length list of different geospatial point positions of a single flow. 674 For example, it could be used to export the start and the end 675 locations of a flow. The template relies on a subTemplateList data 676 type to export the list of geospatial point-based positions. This 677 template requires [RFC6313] compliant Exporting and Collecting 678 Processes. Figure 5 depicts an example of such a subTemplate for 679 exporting each element of the list. 681 0 1 2 3 682 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 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Set ID = 2 | Length = 20 | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Template ID = 302 | Field Count = 2 | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | locationTime = 409 | Field Length = 4 | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | geospatialLocationLat = 402 | Field Length = 8 | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | geospatialLocationLng = 403 | Field Length = 8 | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 Figure 5: Template for exporting a geospatial 2D point-based position 697 Template Record for Geospatial List (ID = 303) 698 | locationMethod(408)[1] 699 | geospatialLocationCRSCode(401)[2] 700 +-subTemplateList(292)[0XFFFF] 701 +-Geospatial 2D Point position Template Record(302)[16] 703 Figure 6: Template for exporting a geospatial list of locations 705 The following presents an example Data Record carrying a list of two 706 geospatial point positions. Each point-based position is defined as 707 an element of a subTemplateList Information Element with semantic 708 "allOf". 710 0 1 2 3 711 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 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Set ID = 303 | Length = 53 | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | locMethod = 3 |geospatialLocationCRSCode=4326 | 255 | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 |Geospatial Point List length=43 |semantic=allOf| Template ID = | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | ... 302 | locationTime = ... | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 |... 1234555555 | geospatialLocationLat1 = ... | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | 43.311 | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | ... octet 8 | geospatialLocationPostLng1 = ... | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | -73.422 | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | ... octet 8 | locationTime = ... | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 |... 1234555555 | geospatialLocationLat2 = | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | 43.111 | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | ... octet 8 | geospatialLocationtLng2 = | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | -73.322 | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | ... octet 8 | 740 +-+-+-+-+-+-+-+-+ 742 Figure 7: Data Record of a geospatial list of point-based locations 744 B.4. Civic Location Template 746 A civic-based location Data Record consists of a tuple of 747 (civicLocationType, civicLocationValue) Information Elements. Each 748 tuple is defined as an element of a subTemplateList Information 749 Element with semantic "allOf". This template requires [RFC6313] 750 compliant Exporting and Collecting Processes. 752 Template Record for Civic location (ID = 304) 753 | locationMethod(408)[1] 754 | locationTime(409)[4] 755 +-subTemplateList (292)[0xFFFF] 756 +-Civic element Template Record (ID = 305) 757 | civiLocationType(406)[1] 758 | civicLocationValue(407)[v] 760 Figure 8: Template for exporting a civic location 762 The "Civic element" Template Record, as shown in Figure 8, MUST be 763 defined for each tuple. For the purpose of illustration, we consider 764 exporting the civic location "Inria Nancy-Grand Est, Building B, 765 Office 123" obtained through DHCP. Using the Template described in 766 Figure 8, the resulting Data Record is as follows: 768 0 1 2 3 769 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 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Set ID = 304 | Length = 62 | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | locMethod = 3 | locationTime = 1234555555 | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | ... octet 4 | 255 |Civic elements list length = 50| 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | semantic=allOf| Civic element TemplateID = 305| CivicType=21 | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | 21 | CivicValue = Inria Nancy-Grand | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Est ... | CivicType=25 | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | 10 | CivicValue = Building | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | B ... | CivicType=28 | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | 10 | CivicValue = Office | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | 123 ... | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 Figure 9: Data Record of a civic location 794 Note that the values of the civiLocationType are defined in 795 [RFC4776]. 797 B.5. Compound Location Template 799 A compound location is used to describe a location, represented by a 800 composite of both civic and geospatial information. An example 801 situation is a two-dimensional geospatial 2D point position 802 (latitude, longitude) describing a location of a building, and a 803 civic element representing the floor in that building. A 804 subTemplateMultiList [RFC6313] SHOULD be used to export a Template 805 for both geospatial and civic information. To represent the above 806 example, the following Template is defined: 808 Template Record for Compound Location (ID = 306) 809 | locationTime(409)[4] 810 +-subTemplateMultiList(293)[0XFFFF] 811 +-Geospatial Template Record (ID = 307) 812 | locationMethod(408)[1] 813 | geospatialLocationCRSCode(401)[2] 814 | geospatialLocationLat(402)[8] 815 | geospatialLocationLng(403)[8] 816 +-Civic location Template Record (ID = 308) 817 | locationMethod(408)[1] 818 | civicLocationType(406)[1] 819 | civicLocationValue(407)[v] 821 Figure 10: Template for exporting a compound location 823 A data Record encoded using the Template shown in Figure 11 is 824 represented as follows: 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Set ID = 311 | Length = 64 | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | locationTime = 12345555555555 | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | 255 | Attributes List Length = 53 | semantic=allOf| 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Template ID = 312 | Geospatial Attr Length = 19 | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | locMethod = 3 |geospatialLocationCRSCode=4326 |geospatial ... | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | ... LocationLat1 = | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | -34.407 |geospatial ... | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | ... LocationLng1 = | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | 150.8883 | Template ID = | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | ... 313 | Civic location Attr length=25 | locMethod=3 | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | CivicType = 21| 21 | CivicValue = Inria ... | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Nancy-Grand Grand Est ... | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 Figure 11: Data Record of a compound location 856 Appendix C. Example Implementation 858 This appendix shows an example application that relies on the set of 859 IPFIX Information Elements described in Appendix A. This application, 860 named SURFmap, is a network monitoring tool based on the Google Maps 861 API that uses Flow data to visualize network Flows on a map 862 [SURFMAP]. By default, geolocation databases are used for retrieving 863 the (estimated) physical location associated to an IP address. The 864 Information Elements described in this document, however, will allow 865 SURFmap to use the absolute location information exported for Flows. 867 SURFmap has been developed in the past as a plugin to NfSen [NFSEN]. 868 NfSen provides a Web-frontend to nfdump [NFDUMP], which is a set of 869 tools for flow data collection and processing, among others. To 870 support collection and processing of Flow Records containing any of 871 the new Information Elements (e.g. by SURFmap), an extension to 872 nfdump has been developed. 874 The following presents a set of Flow Records that have been exported 875 by a mobile Flow Exporter. Several fields, such as destination IP 876 address and port number, location timestamp and location method have 877 been left out for the sake of space. It is clear that the mobile 878 device has moved while exporting Flow Records, as the latitude and 879 longitude coordinates have changed over time. 881 Start time Src IP Addr:Port Pkts Bytes Latitude Longtitude 882 20:19:21.852 173.194.40.113:443 9 2730 48.690855 6.172851 883 20:21:42.307 91.202.200.229:80 13 9137 48.690855 6.172851 884 20:21:42.307 10.21.20.232:59521 15 1547 48.690855 6.172851 885 20:22:38.084 73.194.40.113:80 8 1799 48.690855 6.172851 886 20:22:38.084 10.21.20.232:34056 9 877 48.690855 6.172851 887 21:17:13.498 173.194.45.80:443 12 2830 48.713145 6.17526 888 21:17:13.498 10.21.20.232:49233 15 2301 48.713145 6.17526 889 21:17:16.919 10.21.20.232:15572 1 72 48.744506 6.154815 890 21:17:16.919 172.20.2.39:53 1 257 48.744506 6.15481 892 Normative References 894 [GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape 895 Application Schema for use by the Internet Engineering 896 Task Force (IETF)", Candidate OpenGIS Implementation 897 Specification 06-142r1, Version: 1.0, April 2007. 899 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 900 Requirement Levels", BCP 14, RFC 2119, DOI 901 10.17487/RFC2119, March 1997, . 904 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 905 J. Polk, "Geopriv Requirements", RFC 3693, DOI 906 10.17487/RFC3693, February 2004, . 909 [RFC3694] Danley, M., Mulligan, D., Morris, J., and J. Peterson, 910 "Threat Analysis of the Geopriv Protocol", RFC 3694, DOI 911 10.17487/RFC3694, February 2004, . 914 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 915 Format", RFC 4119, DOI 10.17487/RFC4119, December 2005, 916 . 918 [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol 919 (DHCPv4 and DHCPv6) Option for Civic Addresses 920 Configuration Information", RFC 4776, DOI 921 10.17487/RFC4776, November 2006, . 924 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 925 Format for Presence Information Data Format Location 926 Object (PIDF-LO)", RFC 5139, DOI 10.17487/RFC5139, 927 February 2008, . 929 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 930 "Architecture for IP Flow Information Export", RFC 5470, 931 DOI 10.17487/RFC5470, March 2009, . 934 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 935 Presence Information Data Format Location Object (PIDF-LO) 936 Usage Clarification, Considerations, and Recommendations", 937 RFC 5491, DOI 10.17487/RFC5491, March 2009, 938 . 940 [RFC6225] Polk, J., Linsner, M., Thomson, M., and B. Aboba, Ed., 941 "Dynamic Host Configuration Protocol Options for 942 Coordinate-Based Location Configuration Information", 943 RFC 6225, DOI 10.17487/RFC6225, July 2011, 944 . 946 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization 947 Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, 948 . 950 [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, 951 "Export of Structured Data in IP Flow Information Export 952 (IPFIX)", RFC 6313, DOI 10.17487/RFC6313, July 2011, 953 . 955 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 956 "Specification of the IP Flow Information Export (IPFIX) 957 Protocol for the Exchange of Flow Information", STD 77, 958 RFC 7011, DOI 10.17487/RFC7011, September 2013, 959 . 961 [RFC7012] Claise, B., Ed., and B. Trammell, Ed., "Information Model 962 for IP Flow Information Export (IPFIX)", RFC 7012, DOI 963 10.17487/RFC7012, September 2013, . 966 [RFC7013] Trammell, B. and B. Claise, "Guidelines for Authors and 967 Reviewers of IP Flow Information Export (IPFIX) 968 Information Elements", BCP 184, RFC 7013, DOI 969 10.17487/RFC7013, September 2013, . 972 Informative References 974 [NFDUMP] Haag, P., "NFDUMP", http://nfdump.sourceforge.net, May 975 2013. 977 [NFSEN] Haag, P., "NfSen", http://nfsen.sourceforge.net, January 978 2012. 980 [SURFMAP] Hofstede, R., Fioreze, T., "SURFmap: A Network Monitoring 981 Tool Based on the Google Maps API", Proceedings of the 982 IFIP/IEEE International Symposium on Integrated Network 983 Management, 2009, June 2009. 985 [OGP] Oil and Gas Producers Association, "EPSG Geodetic 986 Parameter Registry", http://www.epsg-registry.org, August 987 2011. 989 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 990 Acronyms", RFC 5513, DOI 10.17487/RFC5513, April 1 2009, 991 . 993 Acknowledgements 995 The authors were partly funded by FLAMINGO, a Network of Excellence 996 project (ICT-318488) supported by the European Commission under its 997 Seventh Framework Programme, and the EIT ICT Labs activity "Smart 998 Networks at the Edge". 1000 Authors' Addresses 1002 Olivier Festor 1003 Inria 1004 615 rue du Jardin Botanique 1005 54600 Villers-les-Nancy 1006 France 1008 Phone: +33 3 83 59 30 66 1009 Email: Olivier.Festor@inria.fr 1011 Abdelkader Lahmadi 1012 University of Lorraine - LORIA 1013 615 rue du Jardin Botanique 1014 54600 Villers-les-Nancy 1015 France 1017 Phone: +33 3 83 59 30 00 1018 Email: Abdelkader.Lahmadi@loria.fr 1020 Rick Hofstede 1021 University of Twente 1022 P.O. Box 217 1023 7500 AE Enschede 1024 The Netherlands 1026 Phone: +31 53 489 2013 1027 Email: r.j.hofstede@utwente.nl 1029 Aiko Pras 1030 University of Twente 1031 P.O. Box 217 1032 7500 AE Enschede 1033 The Netherlands 1035 Phone: +31 53 489 3778 1036 Email: a.pras@utwente.nl