idnits 2.17.1 draft-shen-isis-geo-coordinates-04.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2017) is 2379 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' == Outdated reference: A later version (-02) exists of draft-lamparter-isis-p2mp-01 == Outdated reference: A later version (-07) exists of draft-shen-isis-spine-leaf-ext-03 == Outdated reference: A later version (-15) exists of draft-farinacci-lisp-geo-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group N. Shen, Ed. 3 Internet-Draft E. Chen 4 Intended status: Standards Track A. Lindem 5 Expires: April 21, 2018 Cisco Systems 6 October 18, 2017 8 Carrying Geo Coordinates Information In IS-IS 9 draft-shen-isis-geo-coordinates-04 11 Abstract 13 This document defines a new IS-IS TLV which carries the Geo 14 Coordinates information of the system. The Geo Coordinates 15 information can be used by IS-IS routing or by an application. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 21, 2018. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 53 2. Packet Encoding . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 57 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 58 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 59 8. Document Change Log . . . . . . . . . . . . . . . . . . . . . 7 60 8.1. Changes to draft-shen-isis-geo-coordinates-04.txt . . . . 7 61 8.2. Changes to draft-shen-isis-geo-coordinates-03.txt . . . . 7 62 8.3. Changes to draft-shen-isis-geo-coordinates-02.txt . . . . 7 63 8.4. Changes to draft-shen-isis-geo-coordinates-01.txt . . . . 7 64 8.5. Changes to draft-shen-isis-geo-coordinates-00.txt . . . . 8 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 9.2. Informative References . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 The IS-IS routing protocol defined by [ISO10589] has been widely 73 deployed. The Geo Coordinates information can be useful, 74 particularly within the wide area networks for numerous applications. 75 Similar to the Dynamic Hostname defined in [RFC5301], the Geo 76 Coordinates can also be used for network management purposes. 78 The Geo coordinate information can be retrieve using a variety of 79 means (e.g., SNMP, CLI) without requiring advertising it in an IGP. 80 Nevertheless, announcing the information in IGP allows for new 81 applications and use cases that are elaborated hereafter. 83 The following provides a non-exhaustive list of sample use cases. 85 In the case of IGP point-to-multiple operations 86 [I-D.lamparter-isis-p2mp], [RFC6845], the local system configuration 87 can be greatly simplified if the outbound metric to remote neighbors 88 can be generated automatically based on the Geo Location of the IGP 89 neighbors. 91 In the application where IS-IS neighbors are on the same "sub-net", 92 but over the WAN network, the Geo Location information may be used 93 for equal-cost or unequal-cost load sharing on the local system. 94 This enables location based operation on anycast IP prefixes and DMZ 95 gateways across the WAN environment. 97 For the traffic matrix using the Geo Coordinates within the routing 98 domain, instead of a collection of IP nexthops which might be 99 translated into locations, this enables automatic region to region 100 traffic pattern aggregation. In particular, introducing new nodes or 101 withdrawing existing ones will be automatically reflected by the 102 application responsible for region to region traffic aggregation. 103 Advanced traffic engineering policies may also be enforced to avoid 104 some nodes located on a specific region under some conditions. Such 105 advanced TE policies are not discussed in this document. 107 This document describes the IS-IS protocol extension for carrying the 108 Geo Coordinates information. A new TLV is defined for this purpose. 109 This TLV can be distributed within the node's LSP or inside the IIH 110 PDU. The exact mechanism an application uses the information carried 111 in this TLV is outside the scope of this document. 113 Further, it is out of scope of this document to specify how a node is 114 provided with the information to be included in the TLV. This 115 document does not assume whether the information included in the TLV 116 is static or not. This is deployment-specific. Typically, this 117 information can be used within a mobile network (trains, for example) 118 that is grafted to a global network. 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 2. Packet Encoding 128 This Geo Coordinates extension introduces one TLV for IS-IS LSP PDU 129 and for Hello (IIH) PDU. The code of the TLV is described in 130 Section 4. The fields specify the location of the system using 131 WGS-84 (World Geodetic System) reference coordinate system [WGS84]. 132 The value of the Geo Coordinates TLV consists of the following 133 fields: 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 |U|N|E|A|M|R|K| Reserved | Location Uncertainty | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Lat Degrees | Latitude Milliseconds | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Long Degrees | Longitude Milliseconds | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Altitude | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Radius | Reserved | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | .. Optional Sub-TLVs 149 +-+-+-+-+-+-+-+-+-.... 151 Type: TBD. 8 bits value, to be assigned by IANA. 153 Length: Variable. 8 bits value. The mandatory part is 16 octets. 155 U-bit: If the U-bit is set, it indicates that the "Location 156 Uncertainty" field is specified. If the U-bit is clear, it 157 indicates the "Location Uncertainty" field is unspecified. 159 N-bit: If the N-bit is set, it indicates the Latitude is north 160 relative to the Equator. If the N-bit is clear, it 161 indicates the Latitude is south of the Equator. 163 E-bit: If the E-bit is set, it indicates the Longitude is east of 164 the Prime Meridian. If the E-bit is clear, it indicates the 165 Longitude is west of the Prime Meridian. 167 A-bit: If the A-bit is set, it indicates the "Altitude" field is 168 specified. If the A-bit is clear, it indicates the 169 "Altitude" field is unspecified. 171 M-bit: If the M-bit is set, it indicates the "Altitude" is 172 specified in meters. If the M-bit is clear, it indicates 173 the "Altitude" is in centimeters. 175 R-bit: If the R-bit is set, it indicates the "Radius" field is 176 specified and the encoding is for a circular area. If the 177 R-bit is clear, it indicates the "Radius" field is 178 unspecified and the encoding is for a single point. 180 K-bit: If the K-bit is set, it indicates the "Radius" is specified 181 in kilometers. If the K-bit is clear, it indicates the 182 "Radius" is in meters. 184 Reserved: These bits are reserved. They SHOULD be set to 0 when 185 sending protocol packets and MUST be ignored when receiving 186 protocol packets. 188 Location Uncertainty: Unsigned 16-bit integer indicating the number 189 of centimeters of uncertainty for the location. 191 Latitude Degrees: Unsigned 8-bit integer with a range of 0 - 90 192 degrees north or south of the Equator (northern or southern 193 hemisphere, respectively). 195 Latitude Milliseconds: Unsigned 24-bit integer with a range of 0 - 196 3,599,999 (i.e., less than 60 minutes). 198 Longitude Degrees: Unsigned 8-bit integer with a range of 0 - 180 199 degrees east or west of the Prime Meridian. 201 Longitude Milliseconds: Unsigned 24-bit integer with a range of 0 - 202 3,599,999 (i.e., less than 60 minutes). 204 Altitude: Signed 32-bit integer containing the Height relative to 205 sea level in centimeters or meters. A negative height 206 indicates that the location is below sea level. 208 Radius: Unsigned 16-bit integer containing the radius of a circle 209 centered at the specified coordinates. The radius is 210 specified in meters unless the K-bit is specified indicating 211 specification in kilometers. If the radius is specified, 212 the geo-coordinates specify the entire area of the circle 213 defined by the radius and center point. While the use cases 214 herein do not make use of this field, future use cases may. 216 Optional Sub-TLV: Not defined in this document, for future extension 217 related to the Geo Coordinates information. 219 3. Operations 221 The IS-IS Geo Coordinates TLV may be included in the node's LSP, and 222 it is recommended to be in the LSP fragment zero. This TLV can also 223 be optionally included in the IIH PDU. This can be useful when the 224 application is setting the outbound p2mp circuit metric based on the 225 neighbor's location. This can also be used in the Spine-Leaf 226 extension [I-D.shen-isis-spine-leaf-ext] where there is no LSP being 227 flooded into the leaf nodes. 229 The Geo location information can be provisioned on the system, or it 230 can be dynamically acquired from the GPS capable device on the 231 system. 233 Further, this specification assumes that the Geo Location coordinates 234 MUST NOT be included by default. An explicit configuration parameter 235 is required to instruct an IS-IS node to include this TLV in its 236 announcement. If a node is instructed to include the TLV, but no 237 value is provided, the TLV MUST NOT be announced. 239 4. IANA Considerations 241 A new TLV codepoint is defined in this document and needs to be 242 assigned by IANA from the "IS-IS TLV Codepoints" registry. It is 243 referred to as the Geo Coordinates TLV. This TLV is only to be 244 optionally inserted in the LSP PDU and the IIH PDU. This document 245 does not propose any sub-TLV out of this Geo Coordinates TLV. 247 Value Name IIH LSP SNP Purge 248 ----- --------------------- --- --- --- ----- 249 TBD Geo Coordinates y y n n 251 5. Security Considerations 253 Since the Geo Location coordinates may provide the exact location of 254 the routing devices, disclosure may make the IS-IS devices more 255 susceptible to physical attacks if such IS-IS messages are advertised 256 outside an administrative domain. In situations where this is a 257 concern (e.g., in military applications, or the topology of the 258 network is considered proprietary information), the implementation 259 MUST allow the Geo Location extension to be removed from the IS-IS 260 advertisement. As mentioned in Section 3, the TLV is not included by 261 default. Doing so, allow to avoid misuses of the TLV in the contexts 262 that are not requiring such TLV to be advertised. 264 Security concerns for the base IS-IS are addressed in [ISO10589], 265 [RFC5304], [RFC5310], and [RFC7602]. 267 6. Privacy Considerations 269 If the location of an IS-IS router advertising Geo Location 270 coordinates as described herein can be directly correlated to an 271 individual, individuals, or an organization, the location of that 272 router should be considered sensitive and IS-IS LSP containing such 273 geo coordinates should be advertised confidentially as described in 274 Section 5. Additionally, IS-IS network management facilities may 275 require added authorization to view the contents of IS-IS LSPs 276 containing geo-Location TLVs. Refer to [RFC6973] for more 277 information. 279 The Uncertainty and Confidence metrics for geo-location information 280 as described in [RFC7459] are not included in the Geo Coordinates 281 TLV. In a future document, these may be considered for inclusion 282 with additional Geo Location Sub-TLVs dependent on both on 283 requirements and adoption of [RFC7459]. 285 7. Acknowledgments 287 The encoding of the Geo location is adapted from the "Geo Coordinate 288 LISP Canonical Address Format" specified in the "LISP Canonical 289 Address Format (LCAF)". We would like to thank the authors of that 290 Document and particularly Dino Farinacci for subsequent discussions. 292 Thanks to Mohamed Boucadair, Les Ginsberg, Yi Yang, and Joe 293 Hildebrand for commenting and discussions of Geo Coordinates 294 precision encoding. Thanks to David Ward for commenting on attack 295 vector in relation to this new capability of IS-IS. 297 8. Document Change Log 299 8.1. Changes to draft-shen-isis-geo-coordinates-04.txt 301 o Clarification and more precise descriptions throughout the 302 document thanks to the detailed comments from Mohamed Boucadair. 304 8.2. Changes to draft-shen-isis-geo-coordinates-03.txt 306 o The 03 version submitted in April 2017 without content change. 308 8.3. Changes to draft-shen-isis-geo-coordinates-02.txt 310 o The 02 version submitted in October 2016. 312 o Changed the format of Geo Location encoding to have Radius field 313 and flags to be compatible with LISP [LISP-GEO]. 315 o Added the privacy section. 317 8.4. Changes to draft-shen-isis-geo-coordinates-01.txt 319 o The 01 version submitted in February 2016. 321 o Change Geo Location encoding to have better precision and to 322 include uncertainty information. 324 o Added the discussion in security section for the awareness of 325 increased probability in attack vector. 327 8.5. Changes to draft-shen-isis-geo-coordinates-00.txt 329 o Initial version of the draft is published in February 2016. 331 9. References 333 9.1. Normative References 335 [ISO10589] 336 ISO "International Organization for Standardization", 337 "Intermediate system to Intermediate system intra-domain 338 routeing information exchange protocol for use in 339 conjunction with the protocol for providing the 340 connectionless-mode Network Service (ISO 8473), ISO/IEC 341 10589:2002, Second Edition.", Nov 2002. 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, 345 DOI 10.17487/RFC2119, March 1997, . 348 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 349 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 350 October 2008, . 352 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 353 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 354 2008, . 356 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 357 and M. Fanto, "IS-IS Generic Cryptographic 358 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 359 2009, . 361 [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast 362 and Point-to-Multipoint Interface Type", RFC 6845, 363 DOI 10.17487/RFC6845, January 2013, . 366 [RFC7602] Chunduri, U., Lu, W., Tian, A., and N. Shen, "IS-IS 367 Extended Sequence Number TLV", RFC 7602, 368 DOI 10.17487/RFC7602, July 2015, . 371 9.2. Informative References 373 [I-D.lamparter-isis-p2mp] 374 Franke, C., Lamparter, D., and C. Hopps, "IS-IS Point-to- 375 Multipoint operation", draft-lamparter-isis-p2mp-01 (work 376 in progress), October 2015. 378 [I-D.shen-isis-spine-leaf-ext] 379 Shen, N., Ginsberg, L., and S. Thyamagundalu, "IS-IS 380 Routing for Spine-Leaf Topology", draft-shen-isis-spine- 381 leaf-ext-03 (work in progress), March 2017. 383 [LISP-GEO] 384 Farinacci, D., "LISP Geo-Coordinate Use-Cases", draft- 385 farinacci-lisp-geo-02 (work in progress), 2016. 387 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 388 Morris, J., Hansen, M., and R. Smith, "Privacy 389 Considerations for Internet Protocols", RFC 6973, 390 DOI 10.17487/RFC6973, July 2013, . 393 [RFC7459] Thomson, M. and J. Winterbottom, "Representation of 394 Uncertainty and Confidence in the Presence Information 395 Data Format Location Object (PIDF-LO)", RFC 7459, 396 DOI 10.17487/RFC7459, February 2015, . 399 [WGS84] National Imagery and Mapping Agency, "Department of 400 Defense World Geodetic System 1984, Third Edition", 401 NIMA TR8350.2, January 2000. 403 Authors' Addresses 405 Naiming Shen (editor) 406 Cisco Systems 407 560 McCarthy Blvd. 408 Milpitas, CA 95035 409 US 411 Email: naiming@cisco.com 412 Enke Chen 413 Cisco Systems 414 560 McCarthy Blvd. 415 Milpitas, CA 95035 416 US 418 Email: enkechen@cisco.com 420 Acee Linden 421 Cisco Systems 422 301 Midenhall Way 423 Cary, NC 27513 424 US 426 Email: acee@cisco.com