idnits 2.17.00 (12 Aug 2021) /tmp/idnits18748/draft-taylor-manet-dlep-dsa-00.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 ([I-D.ietf-manet-dlep]), 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 (November 19, 2015) is 2375 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) == Outdated reference: draft-ietf-manet-dlep has been published as RFC 8175 ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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 November 19, 2015 5 Expires: May 22, 2016 7 DLEP Destination Service Announcement 8 draft-taylor-manet-dlep-dsa-00 10 Abstract 12 When using the Dynamic Link Exchange Protocol (DLEP) 13 [I-D.ietf-manet-dlep] to bootstrap neighbour discovery for routing 14 protocols there is no indication in the core DLEP protocol of the 15 services of the router announced at a destination. This forces an 16 implementation to either rely on a priori configuration or use 17 heuristic probing of well-known ports to discover potential routing 18 peers. 20 This document defines an extension to DLEP to enable a router to 21 advertise its active services to its peer modem, allowing a connected 22 remote modem to announce the services of a router in a DLEP 23 destination message to its peer, removing the need for service 24 discovery between routing peers. The mechanism is designed to be 25 sufficiently generic to allow the advertisement of network services 26 beyond routing protocols, enabling the fast bootstrapping of other 27 protocols such as messaging protocols or header compression. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 22, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3.1. Service Descriptors . . . . . . . . . . . . . . . . . . . 4 68 3.1.1. Service Descriptor ABNF . . . . . . . . . . . . . . . 5 69 4. DLEP Signals and Messages for Destination Service 70 Announcement . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5. DLEP Data Items for Destination Service Announcement . . . . 6 72 5.1. IPv4 Destination Service data item . . . . . . . . . . . 6 73 5.2. IPv6 Destination Service data item . . . . . . . . . . . 7 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 7.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 9 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 9.2. Informative References . . . . . . . . . . . . . . . . . 10 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 One of the popular uses of the Dynamic Link Exchange Protocol (DLEP) 86 [I-D.ietf-manet-dlep] is to improve the association time of routing 87 protocol peers. When a DLEP Destination Up message is received by a 88 router, routing protocol instances can be informed of potential 89 peers, enhancing or avoiding the use of timed Hello messages, 90 speeding up the convergence of nodes. In practice this behaviour has 91 many benefits, but does also have a downside: When a new potential 92 peer is announced via DLEP, every routing protocol active on the 93 receiver attempts to communicate with the potential peer trying to 94 form a neighbour association, with no prior indication if the 95 destination router supports the routing protocol. Particularly in a 96 heterogeneous network when the capabilities of different routers is 97 not known in advance, as links form between routers each new router 98 may be bombarded by requests to form a routing adjacency from every 99 protocol implementation active on every other reachable router in the 100 network. 102 This document defines an extension to DLEP that introduces a new data 103 item to allow a router to announce to its DLEP session peer the list 104 of services that it supports, such as the running routing protocols. 105 A modem supporting this extension can transmit this information over 106 the air using whatever internal protocol it uses for signalling to 107 all connected modems. Every other modem can then attach the received 108 list of services to the DLEP Destination Up message that it then 109 sends to its DLEP session peer router. Any changes to the set of 110 services can also be sent via the same mechanism, resulting in a 111 corresponding DLEP Destination Update message. 113 This service announcement may 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 [I-D.ietf-manet-dlep]. No other DLEP extensions are 131 required. 133 This extension also assumes that supporting modems have the facility 134 to transmit the set of services described by an attached router to 135 other modems in the network. 137 3. Operation 139 To announce support for this extension an implementation MUST follow 140 the procedure defined in core DLEP, i.e. Including a DLEP Extension 141 Supported data item in the relevant Session Initialization or Session 142 Initialization Response message. 144 A router uses the Session Update message to advertize its services to 145 its local session modem once it enters the DLEP In-Session state, by 146 including one or more IPv4 Destination Service data items 147 (Section 5.1) and/or IPv6 Destination Service data items 148 (Section 5.2) in the message. 150 When a modem receives a Session Update message from its local router 151 containing one or more Destination Service data items, it SHOULD 152 propogate the change in services to all modems that have previously 153 announced the local router as a DLEP destination. Each remote modem 154 that receives such a notification SHOULD announce the change in 155 remote router services by sending a Destination Update message to 156 their attached router containing one or more Destination Service data 157 items describing the services. 159 When a modem forms a link with a remote modem, it SHOULD announce any 160 services announced by the remote router to its local router by 161 including one or more Destination Service data items in the 162 Destination Up message. 164 In order to retract a previously advertised service or announce a new 165 service, the router MUST send a new Session Update message to the 166 modem containing a relevant Destination Service data item with the 167 Add/Remove flag cleared (zero). 169 Destination Service data items MUST NOT be included in any DLEP 170 Destination message referring to a multicast destination. 172 3.1. Service Descriptors 174 Services active on a router are described using Service Descriptors, 175 that are modelled on DNS SRV records [RFC2782], but with some 176 important differences. A Service Descriptor is a string that 177 describes the name of the service, the IP protocol used by the 178 service, optionally the name of the service instance, and optionally 179 the port number used by the service if not the registered default 180 port. 182 The format of a Service Descriptor string is defined as: 184 Service.Protocol.Name:Port 186 Service: The symbolic name of the desired service, as defined in 187 Assigned Numbers [RFC1700] or locally. The maximum length of a 188 Service is 15 characters. The Service is case insensitive. 190 Protocol: The symbolic name of the desired protocol. 'tcp' and 'udp' 191 are at present the most useful values for this field, though any 192 name defined by Assigned Numbers or locally may be used (as for 193 Service). The Protocol is case insensitive. 195 Name: OPTIONAL. The Name of the instance of the service active at 196 the destination. Unlike DNS SRV records, this name MAY not be a 197 DNS name, but it MUST use the DNS name syntax. The Name is case 198 insensitive. 200 Port: OPTIONAL. The port on router of this service. The range is 201 0-65535. This field SHOULD only be specified if the port differs 202 from the value specified in Assigned Numbers. 204 As mentioned above, the Name field in a service descriptor MUST 205 follow the DNS name syntax, but MAY not be a DNS name, as DLEP is 206 often deployed in envrionments where DNS is not available. However, 207 the Name field still serves a purpose as a descriminiator for 208 different instances of a service and may be used by a receiving 209 router to make peering decisions. 211 When a service operates as an IP protocol, rather than TCP, UDP, SCTP 212 or DCCP, such as OSPF [RFC2328], the Protocol field MUST be specified 213 as 'ip'. 215 3.1.1. Service Descriptor ABNF 217 service-descriptor = service-part "." protocol-part 218 [ "." name-part [ ":" alt-port ] ] 220 service-part = *( 1*DIGIT [ "-" ] ) ALPHA 221 *( [ "-" ] ALNUM ) ; Maximum 15 characters 223 protocol-part = "tcp" / "udp" / "sctp" / "dccp" / "ip" 225 name-part = label *( "." label ) 226 label = ALNUM *( [ "-" ] ALNUM ) 228 alt-port = 1*DIGIT ; Values of 0-65535 230 ALNUM = ALPHA / DIGIT 231 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z [RFC5234] 232 DIGIT = %x30-39 ; 0-9 [RFC5234] 234 4. DLEP Signals and Messages for Destination Service Announcement 236 This extension does not introduce any additional DLEP signals or 237 messages, and does not alter the semantics of any signals or messages 238 defined in the core DLEP specification. 240 5. DLEP Data Items for Destination Service Announcement 242 This extension introduces two (2) new DLEP data items, described 243 below. Both data items carry information about destination services, 244 one for IPv4, the other for IPv6. 246 One or more instances of either or both Destination Service data 247 items MAY appear in the DLEP Session Update, Destination Up, and 248 Destination Update messages. 250 A router MAY use one or more instances of either or both data items 251 in the DLEP Session Update message to advertise all services that are 252 currently available at the router. 254 A modem MAY include one or more instances of either or both data 255 items in the DLEP Destination Up and Destination Update messages to 256 inform locally attached routers of the services available at a remote 257 DLEP destination. 259 A router announcing services MUST NOT report the same combination of 260 address and service in more than one (1) data item per message. A 261 modem that receives multiple data items with the same address and 262 service description in a single message SHOULD treat this as an 263 invalid data item in the message, and react as defined in the core 264 DLEP specification. 266 A modem receiving a Destination Service data item with the Add/Remove 267 flag cleared (zero) MUST retract any previously announced service 268 from it's local router, informing all connected remote modems of the 269 change. If a retraction of a destination service does not match a 270 previous announcement, the implementation SHOULD treat this as an 271 invalid data item and react as defined in the core DLEP 272 specification. 274 5.1. IPv4 Destination Service data item 276 The IPv4 Destination Service data item contains the following fields: 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Data Item Type | Length | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Flags | IPv4 Address : 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 : (cont)... | Service Descriptor... : 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Data Item Type: TBD 290 Length: 5 + the length of Service Descriptor in octets. 292 Flags: Flags field, defined below. 294 IPv4 Address: An IPv4 address used by the announced service. 296 Service Descriptor: A string of characters, as defined in 297 Section 3.1. 299 The Flags field is defined as: 301 0 1 2 3 4 5 6 7 302 +-+-+-+-+-+-+-+-+ 303 | MBZ |A| 304 +-+-+-+-+-+-+-+-+ 306 A: Add/Remove flag, indicating whether this service is being 307 announced as running (1), or whether a previously announced active 308 service is being announced as no longer avaiable at the 309 destination (0). 311 MBZ: MUST be zero. Reserved for future use. 313 An implementation MUST NOT assume the Service Descriptor field is 314 NUL-terminated. 316 5.2. IPv6 Destination Service data item 318 The IPv6 Destination Service data item contains the following fields: 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Data Item Type | Length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Flags | IPv6 Address : 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | IPv6 Address : 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 : IPv6 Address : 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 : IPv6 Address : 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 : IPv6 Address : 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 : | Service Descriptor... : 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Data Item Type: TBD 340 Length: 17 + the length of Service Descriptor in octets. 342 Flags: Flags field, defined below. 344 IPv6 Address: An IPv6 address used by the announced service. 346 Service Descriptor: A string of characters, as defined in 347 Section 3.1. 349 The Flags field is defined as: 351 0 1 2 3 4 5 6 7 352 +-+-+-+-+-+-+-+-+ 353 | MBZ |A| 354 +-+-+-+-+-+-+-+-+ 356 A: Add/Remove flag, indicating whether this service is being 357 announced as running (1), or whether a previously announced active 358 service is being announced as no longer avaiable at the 359 destination (0). 361 MBZ: MUST be zero. Reserved for future use. 363 An implementation MUST NOT assume the Service Descriptor field is 364 NUL-terminated. 366 6. Security Considerations 368 This extension introduces a mechanism for routers to announce their 369 services to other potential peers. In cases where an adversary can 370 manipulate the list of services, by either accessing the network 371 segment between router or modem, or by intercepting any signalling 372 between modems, this list of services may be altered if the link is 373 not secured. 375 Therefore: 377 o Any implementation MUST follow the security considerations defined 378 in the core DLEP protocol. 380 o Any implementation, when used in an environment where the 381 signalling between modems may be open to interception, MUST apply 382 any relevant security considerations for the modem to modem 383 signalling. 385 It should be also noted that a malicious router could attempt to deny 386 service to a network by rapidly and repeatedly announcing a varying 387 set of services, forcing the modems to flood the over the air 388 signalling with updates. A modem implementation MUST be aware of 389 this risk and implement mitigations, such as aggregating the changes 390 and trottling the updates propogated between devices. 392 7. IANA Considerations 394 This section specifies requests to IANA. 396 7.1. Registrations 398 This specification defines two (2) new data items for DLEP. 399 Assignments from the DLEP data item registry are requested for: 401 o IPv6 Destination Service 403 o IPv4 Destination Service 405 The specification also defined an extension to the DLEP protocol. An 406 assignment from the DLEP extension registry is requested for 407 'Destination Service Announcement'. 409 8. Acknowledgements 411 Many thanks to Steve Loates, Stan Ratliff and Henning Rogge for their 412 reviews and feedback. 414 9. References 416 9.1. Normative References 418 [I-D.ietf-manet-dlep] 419 Ratliff, S., Berry, B., Jury, S., Satterwhite, D., and R. 420 Taylor, "Dynamic Link Exchange Protocol (DLEP)", draft- 421 ietf-manet-dlep-17 (work in progress), October 2015. 423 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 424 DOI 10.17487/RFC1700, October 1994, 425 . 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, 429 DOI 10.17487/RFC2119, March 1997, 430 . 432 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 433 Specifications: ABNF", STD 68, RFC 5234, 434 DOI 10.17487/RFC5234, January 2008, 435 . 437 9.2. Informative References 439 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 440 DOI 10.17487/RFC2328, April 1998, 441 . 443 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 444 specifying the location of services (DNS SRV)", RFC 2782, 445 DOI 10.17487/RFC2782, February 2000, 446 . 448 Author's Address 450 Rick Taylor 451 Airbus Defence & Space 452 Quadrant House 453 Celtic Springs 454 Coedkernew 455 Newport NP10 8FZ 456 UK 458 Email: rick.taylor@airbus.com