idnits 2.17.00 (12 Aug 2021) /tmp/idnits21706/draft-taylor-manet-dlep-dsa-01.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 abstract seems to contain references ([RFC8175]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 20, 2017) is 1759 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) ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networks Working Group R. Taylor 3 Internet-Draft Airbus Defence & Space 4 Intended status: Standards Track July 20, 2017 5 Expires: January 21, 2018 7 DLEP Destination Service Announcement 8 draft-taylor-manet-dlep-dsa-01 10 Abstract 12 When using the Dynamic Link Exchange Protocol (DLEP) [RFC8175] to 13 bootstrap neighbour discovery for routing protocols there is no 14 indication in the core DLEP protocol of the services of the router 15 announced at a destination. This forces an implementation to either 16 rely on a priori configuration or use heuristic probing of well-known 17 ports to discover potential routing peers. 19 This document defines an extension to DLEP to enable a router to 20 advertise its active services to its peer modem, allowing a connected 21 remote modem to announce the services of a router in a DLEP 22 destination message to its peer, removing the need for service 23 discovery between routing peers. The mechanism is designed to be 24 sufficiently generic to allow the advertisement of network services 25 beyond routing protocols, enabling the fast bootstrapping of other 26 protocols such as messaging protocols or header compression. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 21, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Service Descriptors . . . . . . . . . . . . . . . . . . . . . 3 66 3.1. Service Descriptor ABNF . . . . . . . . . . . . . . . . . 4 67 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4.1. Service Description Information Base . . . . . . . . . . 5 69 4.2. Over-the-air signalling . . . . . . . . . . . . . . . . . 6 70 5. DLEP Data Items for Destination Service Announcement . . . . 6 71 5.1. IPv4 Destination Service Data Item . . . . . . . . . . . 7 72 5.2. IPv6 Destination Service Data Item . . . . . . . . . . . 8 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 7.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 10 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 9.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 One of the popular uses of the Dynamic Link Exchange Protocol (DLEP) 85 [RFC8175] is to improve the association time of routing protocol 86 peers. When a DLEP Destination Up Message is received by a router, 87 routing protocol instances can be informed of potential peers, 88 enhancing or avoiding the use of timed Hello messages, speeding up 89 the convergence of nodes. In practice this behaviour has many 90 benefits, but does also have a downside: When a new potential peer is 91 announced via DLEP, every routing protocol active on the receiver 92 attempts to communicate with the potential peer trying to form a 93 neighbour association, with no prior indication if the destination 94 router supports the routing protocol. Particularly in a 95 heterogeneous network when the capabilities of different routers is 96 not known in advance, as links form between routers each new router 97 may be bombarded by requests to form a routing adjacency from every 98 protocol implementation active on every other reachable router in the 99 network. 101 This document defines an extension to DLEP that introduces a new Data 102 Item to allow a router to announce to its DLEP session peer, during 103 Session Initialization, the set of services that it supports, such as 104 the running routing protocols. A modem supporting this extension can 105 transmit this information over the air using whatever internal 106 protocol it uses for signalling to all connected modems. Every other 107 modem can then attach the received set of services to the DLEP 108 Destination Up Message that it then sends to its DLEP session peer 109 router. Any changes to the set of services can also be sent via the 110 Session Update Message, resulting in a corresponding DLEP Destination 111 Update Message. 113 This service announcement can be used to advertise the availability 114 of more than just routing protocols. Other protocols that need peers 115 for their operation, such as peer-to-peer messaging applications, or 116 discovering the presence of matching protocol compression proxies, 117 can also use the same mechanism. 119 1.1. Requirements 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in BCP 124 14, RFC 2119 [RFC2119]. 126 2. Assumptions 128 As an extension to DLEP, this document assumes any implementation of 129 this extension correctly implements the core DLEP specification 130 defined in [RFC8175]. No other DLEP extensions are required. 132 This extension also assumes that supporting modems have the facility 133 to transmit the set of services described by an attached router to 134 other modems in the network. 136 3. Service Descriptors 138 Services active on a router are described using Service Descriptors, 139 that are modelled on DNS SRV records [RFC2782], but with some 140 important differences. A Service Descriptor is a string that 141 describes the name of the service, the IP protocol used by the 142 service, optionally the name of the service instance, and optionally 143 the port number used by the service if not the registered default 144 port. 146 The format of a Service Descriptor string is defined as: 148 Service.Protocol.Name:Port 150 Service: The symbolic name of the desired service, as defined in 151 Assigned Numbers [RFC1700] or locally. The maximum length of a 152 Service is 15 characters. The Service is case insensitive. 154 Protocol: The symbolic name of the desired protocol. 'tcp' and 'udp' 155 are at present the most useful values for this field, though any 156 name defined by Assigned Numbers or locally may be used (as for 157 Service). The Protocol is case insensitive. 159 Name: OPTIONAL. The Name of the instance of the service active at 160 the destination. Unlike DNS SRV records, this name MAY not be a 161 DNS name, but it MUST use the DNS name syntax. The Name is case 162 insensitive. 164 Port: OPTIONAL. The port on router of this service. The range is 165 1-65535. This field SHOULD only be specified if the port differs 166 from the value specified in Assigned Numbers. 168 As mentioned above, the Name field in a service descriptor MUST 169 follow the DNS name syntax, but MAY not be a DNS name, as DLEP is 170 often deployed in environments where DNS is not available. However, 171 the Name field still serves a purpose as a descriminiator for 172 different instances of a service and could be used by a receiving 173 router to make peering decisions. 175 When a service operates as an IP protocol, rather than TCP, UDP, SCTP 176 or DCCP, such as OSPF [RFC2328], the Protocol field MUST be specified 177 as 'ip'. 179 3.1. Service Descriptor ABNF 180 service-descriptor = service-part "." protocol-part 181 [ "." name-part [ ":" alt-port ] ] 183 service-part = *( 1*DIGIT [ "-" ] ) ALPHA 184 *( [ "-" ] ALNUM ) ; Maximum 15 characters 186 protocol-part = "tcp" / "udp" / "sctp" / "dccp" / "ip" 188 name-part = label *( "." label ) 189 label = ALNUM *( [ "-" ] ALNUM ) 191 alt-port = %x31-39 *DIGIT ; Values of 1-65535 193 ALNUM = ALPHA / DIGIT 194 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z [RFC5234] 195 DIGIT = %x30-39 ; 0-9 [RFC5234] 197 4. Operation 199 To use this extension, as with all DLEP extensions, the extension 200 MUST be announced during DLEP session initialization. A router 201 advertises support by including the value 'Destination Service 202 Announcement' (TBD1) in the Extension Data Item within the Session 203 Intitialization Message. A modem advertises support by including the 204 value 'Destination Service Announcement' (TBD1) in the Extension Data 205 Item within the Session Intitialization Response Message. If both 206 DLEP peers advertise support for this extension then the Data Items 207 described in this document MAY be used. If a modem does not announce 208 support for this extension, the router MUST NOT include any Data 209 Items described in this document in any DLEP Message. 211 If a router announces support for the 'Destination Service 212 Announcement' extension in the Session Initialization Message, it MAY 213 incude one or more IPv4 Destination Service Data Items (Section 5.1) 214 and/or [IPv6 Destination Service Data Items] (#v6_dca_di) in the 215 Session Initialization Message, as a DLEP compliant modem 216 implementation that does not support this extension will correctly 217 ignore the unknown. 219 4.1. Service Description Information Base 221 In order to describe the correct operation of this extension, a 222 conceptual service descriptor information base is described that 223 contains the set of service descriptors current announced by a router 224 during a DLEP session. A modem that supports this extension is 225 described as maintaining a service descriptor information base 226 recording the set of service descriptors advertised by its local 227 router, ready to relay this information to any over-the-air peers 228 that support this extension with which it forms a link. An 229 implementation is, of course, free to choose alternative ways of 230 providing compliant functionality. 232 When a modem receives a Session Initialization Message from its local 233 router containing an Extension Supported Data Item announcing its 234 support for this extension, and one or more Destination Service Data 235 Items, it records this service information in the service descriptor 236 information base. 238 In order to retract a previously advertised service or announce the 239 availability of a new service, the router sends a new Session Update 240 Message to the modem containing a relevant Destination Service Data 241 Item using the Add/Remove flag to indicate the change. 243 When a modem receives a Session Update Message from its local router 244 containing one or more Destination Service Data Items, it updates the 245 set of service descriptors in its service descriptor information 246 base. 248 4.2. Over-the-air signalling 250 When a modem forms a new link with a remote modem, it sends the 251 contents of the service descriptor information base to the remote 252 modem. How this information is sent is an implementation detail that 253 is out of scope of this document. 255 When a modem supporting this extension receives a set of service 256 descriptors from a remote modem, it SHOULD propogate this information 257 to its DLEP peer router by including one or more Destination Service 258 Data Items in the associated Destination Up Message. 260 When the service descriptor information base of a modem is updated, 261 as a result of a Session Update Message containing one or more 262 Service Description Data Items, it informs all currently connected 263 remote modems of the change. Each remote modem that receives such a 264 notification SHOULD announce the change in remote router services by 265 sending a Destination Update Message to their attached router 266 containing one or more Destination Service Data Items describing the 267 update in services. 269 5. DLEP Data Items for Destination Service Announcement 271 This extension introduces two new DLEP Data Items, described below. 272 Both Data Items carry information about destination services, one for 273 IPv4, the other for IPv6. 275 One or more instances of either or both Destination Service Data 276 Items MAY appear in the DLEP Session Initialization, Session Update, 277 Destination Up, and Destination Update Messages. 279 A router MAY use one or more instances of either or both Data Items 280 in the DLEP Session Initialization Message to advertise all services 281 that are currently available at the router, and a router MAY use one 282 or more instances of either or both Data Items in the DLEP Session 283 Update Message to advertise a change in the services that are 284 currently available at the router. 286 A modem MAY include one or more instances of either or both Data 287 Items in the DLEP Destination Up and Destination Update Messages to 288 inform its DLEP session peer of the services available at a remote 289 DLEP destination. 291 A router announcing services MUST NOT report the same combination of 292 address and service in more than one Data Item per Message. A modem 293 that receives multiple Data Items with the same address and service 294 descriptor in a single Message SHOULD treat this as an invalid Data 295 Item in the Message, and react as defined in the core DLEP 296 specification. 298 A modem receiving a Destination Service Data Item with the Add/Remove 299 flag cleared (zero) retracts any previously announced service from 300 its service descriptor information base, and MUST inform all 301 connected remote modems of the change. If a retraction of a 302 destination service does not match a previous announcement, the 303 implementation SHOULD treat this as an invalid Data Item and react as 304 defined in the core DLEP specification. 306 Destination Service Data Items MUST NOT be included in any DLEP 307 Destination Message referring to a multicast destination. 309 5.1. IPv4 Destination Service Data Item 311 The IPv4 Destination Service Data Item contains the following fields: 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Data Item Type | Length | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Flags | IPv4 Address : 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 : (cont)... | Service Descriptor... : 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Data Item Type: TBD 324 Length: 5 + the length of Service Descriptor in octets. 326 Flags: Flags field, defined below. 328 IPv4 Address: An IPv4 address used by the announced service. 330 Service Descriptor: A string of characters, as defined in Section 3. 332 The Flags field is defined as: 334 0 1 2 3 4 5 6 7 335 +-+-+-+-+-+-+-+-+ 337 | Reserved |A| +-+-+-+-+-+-+-+-+ 339 A: Add/Remove flag, indicating whether this service is being 340 announced as running (1), or whether a previously announced active 341 service is being announced as no longer avaiable at the 342 destination (0). 344 Reserved: MUST be zero. Reserved for future use. 346 An implementation MUST NOT assume the Service Descriptor field is 347 NUL-terminated. 349 5.2. IPv6 Destination Service Data Item 351 The IPv6 Destination Service Data Item contains the following fields: 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Data Item Type | Length | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Flags | IPv6 Address : 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | IPv6 Address : 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 : IPv6 Address : 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 : IPv6 Address : 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 : IPv6 Address : 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 : | Service Descriptor... : 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 Data Item Type: TBD 372 Length: 17 + the length of Service Descriptor in octets. 374 Flags: Flags field, defined below. 376 IPv6 Address: An IPv6 address used by the announced service. 378 Service Descriptor: A string of characters, as defined in Section 3. 380 The Flags field is defined as: 382 0 1 2 3 4 5 6 7 383 +-+-+-+-+-+-+-+-+ 384 | Reserved |A| 385 +-+-+-+-+-+-+-+-+ 387 A: Add/Remove flag, indicating whether this service is being 388 announced as running (1), or whether a previously announced active 389 service is being announced as no longer avaiable at the 390 destination (0). 392 Reserved: MUST be zero. Reserved for future use. 394 An implementation MUST NOT assume the Service Descriptor field is 395 NUL-terminated. 397 6. Security Considerations 399 This extension introduces a mechanism for routers to announce their 400 services to other potential peers. In cases where an adversary can 401 manipulate the list of services, by either accessing the network 402 segment between router or modem, or by intercepting any signalling 403 between modems, this list of services may be altered if the link is 404 not secured. 406 Therefore: 408 o Any implementation MUST follow the security considerations defined 409 in the core DLEP protocol. 411 o Any implementation, when used in an environment where the 412 signalling between modems may be open to interception, MUST apply 413 any relevant security considerations for the modem to modem 414 signalling. 416 It should be also noted that a malicious router could attempt to deny 417 service to a network by rapidly and repeatedly announcing a varying 418 set of services, forcing the modems to flood the over the air 419 signalling with updates. A modem implementation MUST be aware of 420 this risk and implement mitigations, such as aggregating the changes 421 and trottling the updates propogated between devices. 423 7. IANA Considerations 425 This section specifies requests to IANA. 427 7.1. Registrations 429 This specification defines two new Data Items for DLEP. Assignments 430 from the DLEP Data Item registry are requested for: 432 o IPv6 Destination Service 434 o IPv4 Destination Service 436 The specification also defined an extension to the DLEP protocol. An 437 assignment from the DLEP extension registry is requested for 438 'Destination Service Announcement'. 440 8. Acknowledgements 442 Many thanks to Steve Loates, Stan Ratliff and Henning Rogge for their 443 reviews and feedback. 445 9. References 447 9.1. Normative References 449 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 450 DOI 10.17487/RFC1700, October 1994, 451 . 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, 455 DOI 10.17487/RFC2119, March 1997, 456 . 458 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 459 Specifications: ABNF", STD 68, RFC 5234, 460 DOI 10.17487/RFC5234, January 2008, 461 . 463 [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 464 Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, 465 DOI 10.17487/RFC8175, June 2017, 466 . 468 9.2. Informative References 470 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 471 DOI 10.17487/RFC2328, April 1998, 472 . 474 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 475 specifying the location of services (DNS SRV)", RFC 2782, 476 DOI 10.17487/RFC2782, February 2000, 477 . 479 Author's Address 481 Rick Taylor 482 Airbus Defence & Space 483 Quadrant House 484 Celtic Springs 485 Coedkernew 486 Newport NP10 8FZ 487 UK 489 Email: rick.taylor@airbus.com