Mobile Ad hoc Networks Working Group R. Taylor Internet-Draft Airbus Defence & Space Intended status: Standards Track November 19, 2015 Expires: May 22, 2016 DLEP Destination Service Announcement draft-taylor-manet-dlep-dsa-00 Abstract When using the Dynamic Link Exchange Protocol (DLEP) [I-D.ietf-manet-dlep] to bootstrap neighbour discovery for routing protocols there is no indication in the core DLEP protocol of the services of the router announced at a destination. This forces an implementation to either rely on a priori configuration or use heuristic probing of well-known ports to discover potential routing peers. This document defines an extension to DLEP to enable a router to advertise its active services to its peer modem, allowing a connected remote modem to announce the services of a router in a DLEP destination message to its peer, removing the need for service discovery between routing peers. The mechanism is designed to be sufficiently generic to allow the advertisement of network services beyond routing protocols, enabling the fast bootstrapping of other protocols such as messaging protocols or header compression. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 22, 2016. Taylor Expires May 22, 2016 [Page 1] Internet-Draft DLEP Destination Service Announcement November 2015 Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Service Descriptors . . . . . . . . . . . . . . . . . . . 4 3.1.1. Service Descriptor ABNF . . . . . . . . . . . . . . . 5 4. DLEP Signals and Messages for Destination Service Announcement . . . . . . . . . . . . . . . . . . . . . . . . 6 5. DLEP Data Items for Destination Service Announcement . . . . 6 5.1. IPv4 Destination Service data item . . . . . . . . . . . 6 5.2. IPv6 Destination Service data item . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction One of the popular uses of the Dynamic Link Exchange Protocol (DLEP) [I-D.ietf-manet-dlep] is to improve the association time of routing protocol peers. When a DLEP Destination Up message is received by a router, routing protocol instances can be informed of potential peers, enhancing or avoiding the use of timed Hello messages, speeding up the convergence of nodes. In practice this behaviour has many benefits, but does also have a downside: When a new potential peer is announced via DLEP, every routing protocol active on the receiver attempts to communicate with the potential peer trying to Taylor Expires May 22, 2016 [Page 2] Internet-Draft DLEP Destination Service Announcement November 2015 form a neighbour association, with no prior indication if the destination router supports the routing protocol. Particularly in a heterogeneous network when the capabilities of different routers is not known in advance, as links form between routers each new router may be bombarded by requests to form a routing adjacency from every protocol implementation active on every other reachable router in the network. This document defines an extension to DLEP that introduces a new data item to allow a router to announce to its DLEP session peer the list of services that it supports, such as the running routing protocols. A modem supporting this extension can transmit this information over the air using whatever internal protocol it uses for signalling to all connected modems. Every other modem can then attach the received list of services to the DLEP Destination Up message that it then sends to its DLEP session peer router. Any changes to the set of services can also be sent via the same mechanism, resulting in a corresponding DLEP Destination Update message. This service announcement may be used to advertise the availability of more than just routing protocols. Other protocols that need peers for their operation, such as peer-to-peer messaging applications, or discovering the presence of matching protocol compression proxies, can also use the same mechanism. 1.1. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. Assumptions As an extension to DLEP, this document assumes any implementation of this extension correctly implements the core DLEP specification defined in [I-D.ietf-manet-dlep]. No other DLEP extensions are required. This extension also assumes that supporting modems have the facility to transmit the set of services described by an attached router to other modems in the network. 3. Operation To announce support for this extension an implementation MUST follow the procedure defined in core DLEP, i.e. Including a DLEP Extension Taylor Expires May 22, 2016 [Page 3] Internet-Draft DLEP Destination Service Announcement November 2015 Supported data item in the relevant Session Initialization or Session Initialization Response message. A router uses the Session Update message to advertize its services to its local session modem once it enters the DLEP In-Session state, by including one or more IPv4 Destination Service data items (Section 5.1) and/or IPv6 Destination Service data items (Section 5.2) in the message. When a modem receives a Session Update message from its local router containing one or more Destination Service data items, it SHOULD propogate the change in services to all modems that have previously announced the local router as a DLEP destination. Each remote modem that receives such a notification SHOULD announce the change in remote router services by sending a Destination Update message to their attached router containing one or more Destination Service data items describing the services. When a modem forms a link with a remote modem, it SHOULD announce any services announced by the remote router to its local router by including one or more Destination Service data items in the Destination Up message. In order to retract a previously advertised service or announce a new service, the router MUST send a new Session Update message to the modem containing a relevant Destination Service data item with the Add/Remove flag cleared (zero). Destination Service data items MUST NOT be included in any DLEP Destination message referring to a multicast destination. 3.1. Service Descriptors Services active on a router are described using Service Descriptors, that are modelled on DNS SRV records [RFC2782], but with some important differences. A Service Descriptor is a string that describes the name of the service, the IP protocol used by the service, optionally the name of the service instance, and optionally the port number used by the service if not the registered default port. The format of a Service Descriptor string is defined as: Service.Protocol.Name:Port Service: The symbolic name of the desired service, as defined in Assigned Numbers [RFC1700] or locally. The maximum length of a Service is 15 characters. The Service is case insensitive. Taylor Expires May 22, 2016 [Page 4] Internet-Draft DLEP Destination Service Announcement November 2015 Protocol: The symbolic name of the desired protocol. 'tcp' and 'udp' are at present the most useful values for this field, though any name defined by Assigned Numbers or locally may be used (as for Service). The Protocol is case insensitive. Name: OPTIONAL. The Name of the instance of the service active at the destination. Unlike DNS SRV records, this name MAY not be a DNS name, but it MUST use the DNS name syntax. The Name is case insensitive. Port: OPTIONAL. The port on router of this service. The range is 0-65535. This field SHOULD only be specified if the port differs from the value specified in Assigned Numbers. As mentioned above, the Name field in a service descriptor MUST follow the DNS name syntax, but MAY not be a DNS name, as DLEP is often deployed in envrionments where DNS is not available. However, the Name field still serves a purpose as a descriminiator for different instances of a service and may be used by a receiving router to make peering decisions. When a service operates as an IP protocol, rather than TCP, UDP, SCTP or DCCP, such as OSPF [RFC2328], the Protocol field MUST be specified as 'ip'. 3.1.1. Service Descriptor ABNF service-descriptor = service-part "." protocol-part [ "." name-part [ ":" alt-port ] ] service-part = *( 1*DIGIT [ "-" ] ) ALPHA *( [ "-" ] ALNUM ) ; Maximum 15 characters protocol-part = "tcp" / "udp" / "sctp" / "dccp" / "ip" name-part = label *( "." label ) label = ALNUM *( [ "-" ] ALNUM ) alt-port = 1*DIGIT ; Values of 0-65535 ALNUM = ALPHA / DIGIT ALPHA = %x41-5A / %x61-7A ; A-Z / a-z [RFC5234] DIGIT = %x30-39 ; 0-9 [RFC5234] Taylor Expires May 22, 2016 [Page 5] Internet-Draft DLEP Destination Service Announcement November 2015 4. DLEP Signals and Messages for Destination Service Announcement This extension does not introduce any additional DLEP signals or messages, and does not alter the semantics of any signals or messages defined in the core DLEP specification. 5. DLEP Data Items for Destination Service Announcement This extension introduces two (2) new DLEP data items, described below. Both data items carry information about destination services, one for IPv4, the other for IPv6. One or more instances of either or both Destination Service data items MAY appear in the DLEP Session Update, Destination Up, and Destination Update messages. A router MAY use one or more instances of either or both data items in the DLEP Session Update message to advertise all services that are currently available at the router. A modem MAY include one or more instances of either or both data items in the DLEP Destination Up and Destination Update messages to inform locally attached routers of the services available at a remote DLEP destination. A router announcing services MUST NOT report the same combination of address and service in more than one (1) data item per message. A modem that receives multiple data items with the same address and service description in a single message SHOULD treat this as an invalid data item in the message, and react as defined in the core DLEP specification. A modem receiving a Destination Service data item with the Add/Remove flag cleared (zero) MUST retract any previously announced service from it's local router, informing all connected remote modems of the change. If a retraction of a destination service does not match a previous announcement, the implementation SHOULD treat this as an invalid data item and react as defined in the core DLEP specification. 5.1. IPv4 Destination Service data item The IPv4 Destination Service data item contains the following fields: Taylor Expires May 22, 2016 [Page 6] Internet-Draft DLEP Destination Service Announcement November 2015 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | IPv4 Address : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : (cont)... | Service Descriptor... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: 5 + the length of Service Descriptor in octets. Flags: Flags field, defined below. IPv4 Address: An IPv4 address used by the announced service. Service Descriptor: A string of characters, as defined in Section 3.1. The Flags field is defined as: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | MBZ |A| +-+-+-+-+-+-+-+-+ A: Add/Remove flag, indicating whether this service is being announced as running (1), or whether a previously announced active service is being announced as no longer avaiable at the destination (0). MBZ: MUST be zero. Reserved for future use. An implementation MUST NOT assume the Service Descriptor field is NUL-terminated. 5.2. IPv6 Destination Service data item The IPv6 Destination Service data item contains the following fields: Taylor Expires May 22, 2016 [Page 7] Internet-Draft DLEP Destination Service Announcement November 2015 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | IPv6 Address : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IPv6 Address : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IPv6 Address : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IPv6 Address : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : | Service Descriptor... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: 17 + the length of Service Descriptor in octets. Flags: Flags field, defined below. IPv6 Address: An IPv6 address used by the announced service. Service Descriptor: A string of characters, as defined in Section 3.1. The Flags field is defined as: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | MBZ |A| +-+-+-+-+-+-+-+-+ A: Add/Remove flag, indicating whether this service is being announced as running (1), or whether a previously announced active service is being announced as no longer avaiable at the destination (0). MBZ: MUST be zero. Reserved for future use. An implementation MUST NOT assume the Service Descriptor field is NUL-terminated. Taylor Expires May 22, 2016 [Page 8] Internet-Draft DLEP Destination Service Announcement November 2015 6. Security Considerations This extension introduces a mechanism for routers to announce their services to other potential peers. In cases where an adversary can manipulate the list of services, by either accessing the network segment between router or modem, or by intercepting any signalling between modems, this list of services may be altered if the link is not secured. Therefore: o Any implementation MUST follow the security considerations defined in the core DLEP protocol. o Any implementation, when used in an environment where the signalling between modems may be open to interception, MUST apply any relevant security considerations for the modem to modem signalling. It should be also noted that a malicious router could attempt to deny service to a network by rapidly and repeatedly announcing a varying set of services, forcing the modems to flood the over the air signalling with updates. A modem implementation MUST be aware of this risk and implement mitigations, such as aggregating the changes and trottling the updates propogated between devices. 7. IANA Considerations This section specifies requests to IANA. 7.1. Registrations This specification defines two (2) new data items for DLEP. Assignments from the DLEP data item registry are requested for: o IPv6 Destination Service o IPv4 Destination Service The specification also defined an extension to the DLEP protocol. An assignment from the DLEP extension registry is requested for 'Destination Service Announcement'. 8. Acknowledgements Many thanks to Steve Loates, Stan Ratliff and Henning Rogge for their reviews and feedback. Taylor Expires May 22, 2016 [Page 9] Internet-Draft DLEP Destination Service Announcement November 2015 9. References 9.1. Normative References [I-D.ietf-manet-dlep] Ratliff, S., Berry, B., Jury, S., Satterwhite, D., and R. Taylor, "Dynamic Link Exchange Protocol (DLEP)", draft- ietf-manet-dlep-17 (work in progress), October 2015. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, DOI 10.17487/RFC1700, October 1994, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . 9.2. Informative References [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, . Author's Address Rick Taylor Airbus Defence & Space Quadrant House Celtic Springs Coedkernew Newport NP10 8FZ UK Email: rick.taylor@airbus.com Taylor Expires May 22, 2016 [Page 10]