Internet DRAFT - draft-taylor-manet-dlep-dsa
draft-taylor-manet-dlep-dsa
Mobile Ad hoc Networks Working Group R. Taylor
Internet-Draft Airbus Defence & Space
Intended status: Standards Track July 20, 2017
Expires: January 21, 2018
DLEP Destination Service Announcement
draft-taylor-manet-dlep-dsa-01
Abstract
When using the Dynamic Link Exchange Protocol (DLEP) [RFC8175] 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 January 21, 2018.
Taylor Expires January 21, 2018 [Page 1]
Internet-Draft DLEP Destination Service Announcement July 2017
Copyright Notice
Copyright (c) 2017 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. Service Descriptors . . . . . . . . . . . . . . . . . . . . . 3
3.1. Service Descriptor ABNF . . . . . . . . . . . . . . . . . 4
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Service Description Information Base . . . . . . . . . . 5
4.2. Over-the-air signalling . . . . . . . . . . . . . . . . . 6
5. DLEP Data Items for Destination Service Announcement . . . . 6
5.1. IPv4 Destination Service Data Item . . . . . . . . . . . 7
5.2. IPv6 Destination Service Data Item . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. Registrations . . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
One of the popular uses of the Dynamic Link Exchange Protocol (DLEP)
[RFC8175] 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 form a
Taylor Expires January 21, 2018 [Page 2]
Internet-Draft DLEP Destination Service Announcement July 2017
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, during
Session Initialization, the set 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 set 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
Session Update Message, resulting in a corresponding DLEP Destination
Update Message.
This service announcement can 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 [RFC8175]. 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. 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
Taylor Expires January 21, 2018 [Page 3]
Internet-Draft DLEP Destination Service Announcement July 2017
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.
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
1-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 environments where DNS is not available. However,
the Name field still serves a purpose as a descriminiator for
different instances of a service and could 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. Service Descriptor ABNF
Taylor Expires January 21, 2018 [Page 4]
Internet-Draft DLEP Destination Service Announcement July 2017
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 = %x31-39 *DIGIT ; Values of 1-65535
ALNUM = ALPHA / DIGIT
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z [RFC5234]
DIGIT = %x30-39 ; 0-9 [RFC5234]
4. Operation
To use this extension, as with all DLEP extensions, the extension
MUST be announced during DLEP session initialization. A router
advertises support by including the value 'Destination Service
Announcement' (TBD1) in the Extension Data Item within the Session
Intitialization Message. A modem advertises support by including the
value 'Destination Service Announcement' (TBD1) in the Extension Data
Item within the Session Intitialization Response Message. If both
DLEP peers advertise support for this extension then the Data Items
described in this document MAY be used. If a modem does not announce
support for this extension, the router MUST NOT include any Data
Items described in this document in any DLEP Message.
If a router announces support for the 'Destination Service
Announcement' extension in the Session Initialization Message, it MAY
incude one or more IPv4 Destination Service Data Items (Section 5.1)
and/or [IPv6 Destination Service Data Items] (#v6_dca_di) in the
Session Initialization Message, as a DLEP compliant modem
implementation that does not support this extension will correctly
ignore the unknown.
4.1. Service Description Information Base
In order to describe the correct operation of this extension, a
conceptual service descriptor information base is described that
contains the set of service descriptors current announced by a router
during a DLEP session. A modem that supports this extension is
described as maintaining a service descriptor information base
recording the set of service descriptors advertised by its local
router, ready to relay this information to any over-the-air peers
Taylor Expires January 21, 2018 [Page 5]
Internet-Draft DLEP Destination Service Announcement July 2017
that support this extension with which it forms a link. An
implementation is, of course, free to choose alternative ways of
providing compliant functionality.
When a modem receives a Session Initialization Message from its local
router containing an Extension Supported Data Item announcing its
support for this extension, and one or more Destination Service Data
Items, it records this service information in the service descriptor
information base.
In order to retract a previously advertised service or announce the
availability of a new service, the router sends a new Session Update
Message to the modem containing a relevant Destination Service Data
Item using the Add/Remove flag to indicate the change.
When a modem receives a Session Update Message from its local router
containing one or more Destination Service Data Items, it updates the
set of service descriptors in its service descriptor information
base.
4.2. Over-the-air signalling
When a modem forms a new link with a remote modem, it sends the
contents of the service descriptor information base to the remote
modem. How this information is sent is an implementation detail that
is out of scope of this document.
When a modem supporting this extension receives a set of service
descriptors from a remote modem, it SHOULD propogate this information
to its DLEP peer router by including one or more Destination Service
Data Items in the associated Destination Up Message.
When the service descriptor information base of a modem is updated,
as a result of a Session Update Message containing one or more
Service Description Data Items, it informs all currently connected
remote modems of the change. 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
update in services.
5. DLEP Data Items for Destination Service Announcement
This extension introduces two new DLEP Data Items, described below.
Both Data Items carry information about destination services, one for
IPv4, the other for IPv6.
Taylor Expires January 21, 2018 [Page 6]
Internet-Draft DLEP Destination Service Announcement July 2017
One or more instances of either or both Destination Service Data
Items MAY appear in the DLEP Session Initialization, 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 Initialization Message to advertise all services
that are currently available at the router, and a router MAY use one
or more instances of either or both Data Items in the DLEP Session
Update Message to advertise a change in the 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 its DLEP session peer 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 Data Item per Message. A modem
that receives multiple Data Items with the same address and service
descriptor 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) retracts any previously announced service from
its service descriptor information base, and MUST inform 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.
Destination Service Data Items MUST NOT be included in any DLEP
Destination Message referring to a multicast destination.
5.1. IPv4 Destination Service Data Item
The IPv4 Destination Service Data Item contains the following fields:
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... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Taylor Expires January 21, 2018 [Page 7]
Internet-Draft DLEP Destination Service Announcement July 2017
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.
The Flags field is defined as:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |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).
Reserved: 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:
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... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Taylor Expires January 21, 2018 [Page 8]
Internet-Draft DLEP Destination Service Announcement July 2017
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.
The Flags field is defined as:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |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).
Reserved: MUST be zero. Reserved for future use.
An implementation MUST NOT assume the Service Descriptor field is
NUL-terminated.
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
Taylor Expires January 21, 2018 [Page 9]
Internet-Draft DLEP Destination Service Announcement July 2017
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 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.
9. References
9.1. Normative References
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
DOI 10.17487/RFC1700, October 1994,
<http://www.rfc-editor.org/info/rfc1700>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
Taylor Expires January 21, 2018 [Page 10]
Internet-Draft DLEP Destination Service Announcement July 2017
[RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B.
Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175,
DOI 10.17487/RFC8175, June 2017,
<http://www.rfc-editor.org/info/rfc8175>.
9.2. Informative References
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.
[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,
<http://www.rfc-editor.org/info/rfc2782>.
Author's Address
Rick Taylor
Airbus Defence & Space
Quadrant House
Celtic Springs
Coedkernew
Newport NP10 8FZ
UK
Email: rick.taylor@airbus.com
Taylor Expires January 21, 2018 [Page 11]
