Internet DRAFT - draft-herbert-intarea-gue-ctrl-messages
draft-herbert-intarea-gue-ctrl-messages
Internet-Draft T. Herbert
Intended status: Standard track Quantonium
Expires April 4, 2019
October 1, 2018
Control Messages for Generic UDP Encapsulation
draft-herbert-intarea-gue-ctrl-messages-00
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 4, 2019.
Copyright Notice
Copyright (c) 2018 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.
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
Herbert Expires April, 2019 [Page 1]
Internet Draft GUE Control Messages October 1, 2018
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.
Herbert Expires April, 2019 [Page 2]
Internet Draft GUE Control Messages October 1, 2018
Abstract
This specification defines a set of basic control messages for
Generic UDP Encapsulation (GUE). One pair of messages provides a
means to query the GUE capabilities of a peer, another pair defines
an echo request and response exchange for testing reachability.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Requirements Language . . . . . . . . . . . . . . . . . . . 4
2 GUE capabilities query and response messages . . . . . . . . . 5
2.1 Capabilities query message . . . . . . . . . . . . . . . . . 5
2.2 Capabilities response message . . . . . . . . . . . . . . . 6
2.3 Capabilities TLV format . . . . . . . . . . . . . . . . . . 7
2.4 TLV types . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.1 GUE variants . . . . . . . . . . . . . . . . . . . . . . 7
2.4.2 Control message types . . . . . . . . . . . . . . . . . 8
2.4.3 GUE flags . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.4 Payload transform types . . . . . . . . . . . . . . . . 9
2.5 Operation . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.1 Sending a capabilities query . . . . . . . . . . . . . . 9
2.5.2 Receiving a capabilities query . . . . . . . . . . . . . 9
2.5.3 Validating a capabilities response message . . . . . . . 10
2.5.4 Processing a capabilities response . . . . . . . . . . . 10
3 Echo request and reply messages . . . . . . . . . . . . . . . . 11
3.1 Echo request . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1 Optional echo data format . . . . . . . . . . . . . . . 12
3.2 Echo reply . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Operation . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1 Sending an echo request . . . . . . . . . . . . . . . . 13
3.4.2 Receiving an echo request . . . . . . . . . . . . . . . 14
3.4.3 Receiving an echo reply . . . . . . . . . . . . . . . . 14
3.5 Testing GUE capabilities . . . . . . . . . . . . . . . . . . 14
4 Security considerations . . . . . . . . . . . . . . . . . . . . 14
5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15
5.1 GUE control messages . . . . . . . . . . . . . . . . . . . . 15
5.2 GUE capabilities TLV types . . . . . . . . . . . . . . . . . 15
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1 Normative References . . . . . . . . . . . . . . . . . . . . 16
6.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Herbert Expires April, 2019 [Page 3]
Internet Draft GUE Control Messages October 1, 2018
1 Introduction
This specification describes some basic control messages for Generic
UDP Encapsulation (GUE). A capabilities query message and response
message are defined for a node to query a peer GUE node for supported
capabilities. Echo request and echo reply control messages are
defined to verify reachability and measure latency to a GUE peer
node.
The capabilities query is used to ascertain the capabilities of a
peer for receiving GUE messages. For instance, a node may query a GUE
peer to determine what GUE variants it supports, or what flags are
supported for GUE variant 0. A capabilities query control message and
a capabilities response control message are defined. A response
message indicates the capabilities for receiving GUE messages. A node
may send a capabilities query to a peer GUE node and based on the
response it may subsequently use supported flags, optional
extensions, GUE variants, or control messages when sending GUE
messages to the peer.
Echo request and response messages are used to test for reachability
and liveness of a GUE peer node. A node sends an echo request control
message and a peer will respond with an echo reply control message.
Upon receiving an echo reply, reachability to the GUE peer node is
considered verified. The echo request includes arbitrary data that is
reflected by the peer in an echo reply. The echo data may contain a
timestamp and identifier to perform round trip latency measurement.
1.1 Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Herbert Expires April, 2019 [Page 4]
Internet Draft GUE Control Messages October 1, 2018
2 GUE capabilities query and response messages
This section describes the GUE capabilities query and response
messages.
2.1 Capabilities query message
A GUE capabilities query message has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
| 0 |1| Hlen | 0x1 | Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ G
| | U
~ Extensions Fields (optional) ~ E
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ h
| | d
~ Private data (optional) ~ r
| |/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Query identifier +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pertinent GUE header fields are:
o C bit: Set to 1 to indicate a control message
o Proto/ctype: Set to 0x1 to indicate a capabilities query message
GUE flags, extension fields, and private data SHOULD NOT be used in a
capabilities query message.
Control message fields are:
o Query identifier: Used to match queries with responses. This is
set to a different non-zero random value in each query.
Herbert Expires April, 2019 [Page 5]
Internet Draft GUE Control Messages October 1, 2018
2.2 Capabilities response message
A GUE capabilities response message has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
| 0 |1| Hlen | 0x2 | Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ G
| | U
~ Extensions Fields (optional) ~ E
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ h
| | d
~ Private data (optional) ~ r
| |/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Query identifier +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Capabilities TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pertinent GUE header fields are:
o C bit: Set to 1 to indicate a control message
o Proto/ctype: Set to 0x2 to indicate a capabilities response
message
GUE flags, extension fields, and private data SHOULD NOT be used in a
capabilities response message.
Control message fields are:
o Query identifier: Reflected value from the capabilities query
message
o Capabilities TLVs: A set of Type Length Value (TLV) structures
that describe the capabilities of the reporting node
Herbert Expires April, 2019 [Page 6]
Internet Draft GUE Control Messages October 1, 2018
2.3 Capabilities TLV format
Capabilities TLVs have the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
o Type: Type for TLV. Defined types are described below
o Length: Length in bytes of a TLV Value. Note that this length
does not include the two bytes for Type and Length.
o Value: Data for the TLV
2.4 TLV types
The table below lists the TLVs defined in this document. The "Length"
column indicates any required limits on TLVs, and the "Typical
Length" column indicates the most useful lengths for the TLV.
Type Length Typical Length Meaning
---------------------------------------------------------------------
0 RESERVED
1 variable 1 GUE variants
2 variable 1 to 32 Control message types
3 variable 2 (currently) GUE flags/extensions
4 variable 1 to 32 Payload transform types
5-126 UNASSIGNED (assignable by IANA)
127-255 User defined
2.4.1 GUE variants
This TLV reports the GUE variants that are support by a node.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x1 | Length (1) | Bit map ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Herbert Expires April, 2019 [Page 7]
Internet Draft GUE Control Messages October 1, 2018
The TLV data is a variable length bit map of supported GUE variants.
Bit 0 in the data indicates variant 0 is supported, bit 1 in the data
indicates variant 1 is supported, etc. GUE allows up to four variants
where variants 0 and 1 have been defined, so only the first four bits
in the map are meaningful. If bits are set the map after the fourth
bit they are ignored. Similarly, any bytes in the data beyond the
first byte are ignored.
Variant 0 must be supported so bit 0 should always be set.
2.4.2 Control message types
This TLV reports the control message types that are supported by a
node.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x2 | Length (1-32) | Bit map ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TLV data is a bit map of supported control message types. Bit 0
in the data indicates control message 0 is supported, bit 1 in the
data indicates control message 1 is supported, etc. The range of
values for a control message type is 0 to 255, so the maximum useful
length of the TLV data is sixteen bytes. If the data length is
greater than sixteen bytes then the additional bytes are ignored.
The bit for control message 0 should be set since that value is used
to indicate that the payload cannot be parsed as a control message
[GUE]. Control message 1 should also be marked as supported given
that fact the capabilities represented in the TLV are sent in
response to a capabilities query control message which has type of 1.
2.4.3 GUE flags
This TLV reports the GUE flags that are supported by a node. In the
case that flags refer to option extensions, the TLV indicates support
for the extensions.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x3 | Length (>=2) | Bit map ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TLV data is a bit map of supported GUE flags. Bit 0 in the data
indicates the flag corresponding to bit 0 of GUE flags is supported,
bit 1 indicates the flag for the second bit in GUE flags is
supported, etc.
Herbert Expires April, 2019 [Page 8]
Internet Draft GUE Control Messages October 1, 2018
For a multi-bit (paired) flag, the corresponding bits in the bit map
are taken to be the maximum value supported for the multi-bit flag.
For instance, with a three bit flag, a value of 0x2 indicates flag
combinations 0x1 and 0x2 are supported. A value of 0x7 indicates that
all seven combinations are supported. If more granularity is needed,
for example only values 0x1 and 0x3 are supported, then an additional
TLV can be defined to described supported combinations of a multi-bit
flag.
2.4.4 Payload transform types
This TLV reports the types of the Payload Transform optional
extension that a node supports.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x3 | Length (1-32) | Bit map ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The TLV data is a bit map of supported payload transform types. Bit 0
in the data indicates payload transform type 0 is supported, bit 1 in
the data indicates payload transform type 1 is supported, etc. The
range of values for a payload transform type is 0 to 255, so the
maximum useful length of the TLV data is sixteen bytes. If the data
length is greater than sixteen bytes then the additional bytes are
ignored.
2.5 Operation
This section describes the operation of capabilities query and
response messages.
2.5.1 Sending a capabilities query
A GUE node MAY send a capabilities request to a peer. The request is
a well formatted GUE control message. The Query Identifier MUST be
set to a non-zero value and SHOULD random. The sender SHOULD save the
Query Identifier in a query context to match a response. The sender
SHOULD set a timer to receive a response. If no response is received
before timeout, then the request context is released.
2.5.2 Receiving a capabilities query
When a node receives a capabilities query it MAY send a response
message. The Query Identifier that was received in the query message
is reflected in response. The responding node creates the TLVs for
capabilities that it wishes to report. A node is not obligated to
report all implemented capabilities and may tailor its response per
the identity of the requestor. It may withhold reporting of
Herbert Expires April, 2019 [Page 9]
Internet Draft GUE Control Messages October 1, 2018
capabilities for security reasons; for instance, the security option
is only useful between two peers if keys are negotiated out of band
so indicating support in a capabilities response is not necessary.
2.5.3 Validating a capabilities response message
Upon receiving a capabilities response message, it MUST be validated.
A node SHOULD match the Query Identifier with a recent request that
it has sent. If it is unable to match the response to a sent query
then the response message SHOULD be dropped. A node MAY choose to
match the source address of the response message to the destination
address to which it sent the request. Note that GUE does not require
addresses to be consistent in the reverse direction. A node may
receive a capabilities response sourced from a different address than
what it sent the request to; in that case matching the Query
Identifier should be sufficient.
If the length of the last TLV exceeds the extent of the packet, then
the query response message MUST be dropped. Unknown TLVs are skipped
over, as are individual TLVs that have a mismatch in required length
or bad data per the requirements of the TLV. TLVs may be sent in any
order, may be present more than once in a packet, and the number of
TLVs in a message is only limited by packet size. A receiving node
may place limits on number or types of TLVs it processes.
2.5.4 Processing a capabilities response
If a valid capabilities response message is received, a node may
assume that capabilities indicated in the TLVs are supported by the
peer. The node can send GUE packets using those capabilities with the
expectation that the peer node will process them. If a capability
isn't indicated as being supported, then a node SHOULD assume its
peer doesn't support the capability and not use it. A node MAY have
other information (e.g. out of band configuration) that a peer does
support a capability, in which case the capability could be used.
A capabilities query and response exchange is not a protocol
negotiation, nor does it establish explicit connection-like state.
The reported capabilities should be considered as advisory, and the
attained information may be valid for a limited time. It is possible
that a node may change its supported capabilities, may refer to a
virtual IP address (VIP) where backend nodes support different
capabilities, or the address for a peer is reassigned to a node that
doesn't support the same capabilities. A node MAY resend capabilities
queries to a destination if it suspects that the supported
capabilities might change. The echo request and reply mechanism can
also be used to test that reported capabilities are supported.
Herbert Expires April, 2019 [Page 10]
Internet Draft GUE Control Messages October 1, 2018
3 Echo request and reply messages
This section describes the GUE echo request and echo response control
messages.
3.1 Echo request
A GUE echo request message has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
| 0 |1| Hlen | 0x3 | Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ G
| | U
~ Extensions Fields (optional) ~ E
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ h
| | d
~ Private data (optional) ~ r
| |/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pertinent GUE header fields are:
o C bit: Set to 1 to indicate a control message
o Proto/ctype: Set to 0x3 to indicate an echo request message
GUE flags, extension fields, and private data MAY be used in an echo
request.
Control message fields are:
o Data: Contains arbitrary data set by the sender. This MAY
contain an identifier to match replies with echo requests, and
MAY contain a timestamp to measure round trip time.
Note that the data in an echo request is only interpretable by the
sender of the echo request. A node receiving an echo request should
not attempt to parse the data or interpret it, it should only reflect
the data in an echo response.
Herbert Expires April, 2019 [Page 11]
Internet Draft GUE Control Messages October 1, 2018
3.1.1 Optional echo data format
A node MAY use the following format for the echo data. This format
includes a transaction identifier, sequence number, and timestamp to
facilitate matching replies to requests and measuring round trip
latency.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Transaction identifier +
| |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
o Transaction identifier: Used to match replies with requests.
This should be randomly set to a different value for each
different destination
o Sequence number: Monotomically increasing counter for sending
multiple echo requests to the same node using the same the
transaction identifier
o Timestamp: Timestamp set by the echo request sender and
reflected in a echo reply. Normally, this is a value taken from
the system clock of the sender. The round trip latency is
computed as the time the echo response was received minus the
timestamp value received in the echo response. The meaning and
units of the timestamp are local to the echo request sender
o Data: Additional data that may be of relevance to the sender
Herbert Expires April, 2019 [Page 12]
Internet Draft GUE Control Messages October 1, 2018
3.2 Echo reply
A GUE echo reply message has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
| 0 |1| Hlen | 0x4 | Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ G
| | U
~ Extensions Fields (optional) ~ E
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ h
| | d
~ Private data (optional) ~ r
| |/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pertinent GUE header fields are:
o C bit: Set to 1 to indicate a control message
o Proto/ctype: Set to 0x4 to indicate an echo reply message
GUE flags, extension fields, and private data MAY be used in an echo
reply.
Control message fields are:
o Data: Reflected data that was received in an echo request
3.4 Operation
This section describes the operation of echo request and echo reply
messages.
3.4.1 Sending an echo request
A node MAY send an echo request message to a peer to determine
reachability or measure round trip latency. An echo request is a GUE
control message that includes optional data to be reflected by a
peer. A node MAY set GUE flags, extensions, and private data--
particularly to test support for these as described below.
Herbert Expires April, 2019 [Page 13]
Internet Draft GUE Control Messages October 1, 2018
If a Transaction Identifier is used in the echo data then the sender
SHOULD save it in an echo request context to match to an echo reply.
The sender SHOULD set a timer to receive a response. If no response
is received before timeout then the echo request context is released.
3.4.2 Receiving an echo request
When a node receives an echo request, an echo response message SHOULD
be created and sent back to the source address of the echo request
message. A response message SHOULD NOT set any GUE flags, extensions
or private data. An exception is if the packet size exceeds MTU then
the GUE fragmentation option MAY be used.
3.4.3 Receiving an echo reply
A node SHOULD match a received echo reply to an echo request that it
recently sent. If the node sent a Transaction Identifier in an echo
request then the value in an echo reply can be matched. Otherwise, an
echo reply can be matched to a request based on the source address of
the reply message matching the destination address of a recently sent
request message. If sequence numbers are present they may be used to
track individual echo requests and to report losses.
3.5 Testing GUE capabilities
A node MAY probe the capabilities that a GUE node supports by using
the capabilities in an echo request. For instance, a node could set
the remote checksum offload option in an echo request. If a
corresponding echo reply is received then the node may deduce that
its peer supports the feature. This mechanism can be used to verify
that capabilities reported in a capabilities response are indeed
supported by a peer node.
4 Security considerations
A capabilities response potentially contains detailed information
about a system that might be of interest to an attacker. A node MAY
choose not to respond to capabilities queries from untrusted nodes,
or it may selectively curtail providing information about its
capabilities.
Unsolicited capabilities response messages SHOULD NOT be accepted by
a node. If a capabilities response is received, then the enclosed
Query Identifier SHOULD be matched to a recent query that the node
has sent. This is to prevent a attacker from spoofing someone else's
address and reporting random capabilities are supported as an
attempted Denial of Service attack.
Herbert Expires April, 2019 [Page 14]
Internet Draft GUE Control Messages October 1, 2018
A node MAY rate limit capabilities response messages and echo reply
messages to mitigate Denial of Service attacks.
5 IANA Considerations
5.1 GUE control messages
IANA is requested to assign four values in the registry for the GUE
control types:
+----------------+------------------+---------------+
| Control type | Description | Reference |
+----------------+------------------+---------------+
| 0x1 | Capabilities | This document |
| | query | |
| | | |
| 0x2 | Capabilities | This document |
| | response | |
| | | |
| 0x3 | Echo request | This document |
| | | |
| 0x4 | Echo reply | This document |
+----------------+------------------+---------------+
5.2 GUE capabilities TLV types
Upon publication, IANA is hereby requested to create a new registry
for GUE capabilities TLV types. Initial values of this registry are
as listed in Section 2.4.
Herbert Expires April, 2019 [Page 15]
Internet Draft GUE Control Messages October 1, 2018
6 References
6.1 Normative References
[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>.
[GUE] T. Herbert, L. Yong, and O. Zia, "Generic UDP
Encapsulation" draft-ietf-intarea-gue-06
6.2. Informative References
[GUEEXTEN] Herbert, T., Yong, L., and Templin, F., "Extensions for
Generic UDP Encapsulation" draft-ietf-intarea-gue-
extensions-05
Author's Address
Tom Herbert
Quantonium
4701 Patrick Henry
Santa Clara, CA 95054
US
Email: tom@herbertland.com
Herbert Expires April, 2019 [Page 16]
