< draft-herbert-gue-extensions-00.txt   draft-herbert-gue-extensions-01.txt >
INTERNET-DRAFT T. Herbert INTERNET-DRAFT T. Herbert
Intended Status: Proposed Standard Facebook Intended Status: Proposed Standard Facebook
Expires: December 2016 L. Yong Expires: May 1, 2017 L. Yong
Huawei Huawei
F. Templin F. Templin
Boeing Boeing
June 21, 2016 October 28, 2016
Extensions for Generic UDP Encapsulation Extensions for Generic UDP Encapsulation
draft-herbert-gue-extensions-00 draft-herbert-gue-extensions-01
Abstract Abstract
This specification defines a set of the fundamental extensions for This specification defines a set of the fundamental optional
Generic UDP Encapsulation (GUE). The extensions defined in this extensions for Generic UDP Encapsulation (GUE). The extensions
specification are the security option, payload transform option, defined in this specification are the security option, payload
checksum option, fragmentation option, and the remote checksum transform option, checksum option, fragmentation option, and the
offload option. remote checksum offload option.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 18 skipping to change at page 2, line 18
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. GUE header format with options . . . . . . . . . . . . . . . . 4 2. GUE header format with optional extensions . . . . . . . . . . 4
3. Checksum option . . . . . . . . . . . . . . . . . . . . . . . 5 3. Security option . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Extension field format . . . . . . . . . . . . . . . . . . 6
3.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. GUE checksum pseudo header . . . . . . . . . . . . . . . . 7 3.3. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Checksum computation . . . . . . . . . . . . . . . . . . . 8 3.4. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Transmitter operation . . . . . . . . . . . . . . . . . . 8 3.4.1. Extension field format . . . . . . . . . . . . . . . . 7
3.6. Receiver operation . . . . . . . . . . . . . . . . . . . . 8 3.4.2. Selecting a hash algorithm . . . . . . . . . . . . . . 8
3.7. Security Considerations . . . . . . . . . . . . . . . . . 9 3.4.3. Pre-shared key management . . . . . . . . . . . . . . . 8
3.5. Interaction with other optional extensions . . . . . . . . 9
4. Fragmentation option . . . . . . . . . . . . . . . . . . . . . 9 4. Fragmentation option . . . . . . . . . . . . . . . . . . . . . 9
4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Option format . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Extension field format . . . . . . . . . . . . . . . . . . 11
4.4. Fragmentation procedure . . . . . . . . . . . . . . . . . 12 4.4. Fragmentation procedure . . . . . . . . . . . . . . . . . 12
4.5. Reassembly procedure . . . . . . . . . . . . . . . . . . . 14 4.5. Reassembly procedure . . . . . . . . . . . . . . . . . . . 14
4.6. Security Considerations . . . . . . . . . . . . . . . . . 16 4.6. Security Considerations . . . . . . . . . . . . . . . . . 16
5. Security and payload transform options . . . . . . . . . . . . 16 5. Payload transform option . . . . . . . . . . . . . . . . . . . 16
5.1. Security option format . . . . . . . . . . . . . . . . . . 16 5.1. Extension field format . . . . . . . . . . . . . . . . . . 16
5.2. Security option usage . . . . . . . . . . . . . . . . . . 17 5.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.1. Cookies . . . . . . . . . . . . . . . . . . . . . . . 17 5.3. Interaction with other optional extensions . . . . . . . . 17
5.2.2. Secure hash . . . . . . . . . . . . . . . . . . . . . 18 5.4. DTLS transform . . . . . . . . . . . . . . . . . . . . . . 18
5.3. Payload Transform Option format . . . . . . . . . . . . . 18 6. Remote checksum offload option . . . . . . . . . . . . . . . . 18
5.3.1. Payload transform option usage . . . . . . . . . . . . 19 6.1. Extension field format . . . . . . . . . . . . . . . . . . 19
5.4. Operation of security mechanisms . . . . . . . . . . . . . 19 6.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.5. Considerations of Using Other Security Tunnel Mechanisms . 20 6.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 19
6. Remote checksum offload option . . . . . . . . . . . . . . . . 21 6.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 20
6.1. Option format . . . . . . . . . . . . . . . . . . . . . . 21 6.3. Security Considerations . . . . . . . . . . . . . . . . . 21
6.2. Transmitter operation . . . . . . . . . . . . . . . . . . 22 7. Checksum option . . . . . . . . . . . . . . . . . . . . . . . 21
6.3. Receiver operation . . . . . . . . . . . . . . . . . . . . 22 7.1. Extension field format . . . . . . . . . . . . . . . . . . 21
6.4. Security Considerations . . . . . . . . . . . . . . . . . 23 7.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 22
7. Processing order of options . . . . . . . . . . . . . . . . . 23 7.3. GUE checksum pseudo header . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 25 7.4.1. Transmitter operation . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.4.2.Receiver operation . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 25 7.5. Security Considerations . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 25 8. Processing order of options . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References . . . . . . . . . . . . . . . . . . 27
11.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Generic UDP Encapsulation [I.D.nvo3-gue] is a generic and extensible Generic UDP Encapsulation (GUE) [I.D.nvo3-gue] is a generic and
encapsulation protocol. This specification defines a basic set of extensible encapsulation protocol. This specification defines a
extensions for GUE. These extensions are the security option, payload fundamental set of optional extensions for version 0 of GUE. These
transform option, checksum option, fragmentation option, and the extensions are the security option, payload transform option,
remote checksum offload option. checksum option, fragmentation option, and the remote checksum
offload option.
2. GUE header format with options 2. GUE header format with optional extensions
The general format of GUE with the options defined in this The format of a version 0 GUE header with the optional extensions
specification is: defined in this specification is:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
| Source port | Destination port | \ | Source port | Destination port | UDP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
| Length | Checksum | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
|Ver|C| Hlen | Proto/ctype |V|SEC|K|F|T|R| Rsvd Flags | | Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |C| Hlen | Proto/ctype |V| SEC |F|T|R|K| Rsvd Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VNID (optional) | | VNID (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Security (optional) ~ ~ Security (optional) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Fragmentation (optional) + + Fragmentation (optional) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload transform (optional | | Payload transform (optional |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote checksum offload (optional) | | Remote checksum offload (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Private fields (optional) ~ ~ Private data (optional) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of the UDP are described in [I.D.herbert-gue]. The contents of the UDP header are described in [I.D.herbert-gue].
The GUE header consists of: The GUE header consists of:
o Ver: Version. Set to 0x0 to indicate GUE encapsulation header. o Ver: Version. Set to 0 to indicate GUE encapsulation header.
Note that version 1 does not allow options.
Note that version 0x1 does not allow options.
o C: Control bit. May be set or unset. GUE options can be used o C: C-bit. Indicates the GUE payload is a control message when
with either control or data packets unless otherwise specified set, a data message when not set. GUE optional extensions can be
in the option definition. used with either control or data messages unless otherwise
specified in the option definition.
o Hlen: Length in 32-bit words of the GUE header, including o Hlen: Length in 32-bit words of the GUE header, including
optional fields but not the first four bytes of the header. optional extension fields but not the first four bytes of the
Computed as (header_len - 4) / 4. The length of the encapsulated header. Computed as (header_len - 4) / 4. The length of the
packet is determined from the UDP length and the Hlen: encapsulated packet is determined from the UDP length and the
encapsulated_packet_length = UDP_Length - 8 - GUE_Hlen. Hlen: encapsulated_packet_length = UDP_Length - 12 - 4*Hlen.
o Proto/ctype: If the C bit is not set this indicates IP protocol o Proto/ctype: If the C-bit is not set this indicates IP protocol
number for the packet in the payload, else if the C bit is set number for the packet in the payload; if the C bit is set this
this type of control message for the payload. The next header is the type of control message in the payload. The next header
begins at the offset provided by Hlen. When the fragmentation begins at the offset provided by Hlen. When the payload
option or payload transform option is used this field may be set transform option or fragmentation option is used this field may
to protocol number 59 for a data message, or a value of 0 for a be set to protocol number 59 for a data message, or zero for a
control message, to indicate no next header for the payload. control message, to indicate no next header for the payload.
o V: Indicates the network virtualization option (VNID) field is o V: Indicates the network virtualization extension (VNID) field
present. The VNID option is described in [I.D.hy-nvo3-gue-4- is present. The VNID option is described in [I.D.hy-nvo3-gue-4-
nvo]. nvo].
o SEC: Indicates security option field is present. The security o SEC: Indicates security extension field is present. The security
option is described in section 5.
o K: Indicates checksum option field is present. The checksum
option is described in section 3. option is described in section 3.
o F: Indicates fragmentation option field is present. The o F: Indicates fragmentation extension field is present. The
fragmentation option is described in section 4. fragmentation option is described in section 4.
o T: Indicates transform option field is present. The transform o T: Indicates payload transform extension field is present. The
option is described in section 5. payload transform option is described in section 5.
o R: Indicates the remote checksum option field is present. The o R: Indicates the remote checksum extension field is present. The
remote checksum offload option is described in section 6. remote checksum offload option is described in section 6.
o Private fields are described in [I.D.nvo3-gue]. o K: Indicates checksum extension field is present. The checksum
option is described in section 7.
3. Checksum option o Private data is described in [I.D.nvo3-gue].
The GUE checksum option provides a checksum that covers the GUE 3. Security option
header, a GUE pseudo header, and optionally part or all of the GUE
payload. The GUE pseudo header includes the corresponding IP
addresses as well as the UDP ports of the encapsulating headers. This
checksum should provide adequate protection against address
corruption in IPv6 when the UDP checksum is zero. Additionally, the
GUE checksum provides protection of the GUE header when the UDP
checksum is set to zero with either IPv4 or IPv6. In particular, the
GUE checksum can provide protection for some sensitive data, such as
the virtual network identifier ([I.D.hy-nvo3-gue-4-nvo]), which when
corrupted could lead to mis-delivery of a packet to the wrong virtual
network.
3.1. Option format The GUE security option provides origin authentication and integrity
protection of the GUE header at tunnel end points to guarantee
isolation between tunnels and mitigate Denial of Service attacks.
The presence of the GUE checksum option is indicated by the K bit in 3.1. Extension field format
the GUE header.
The format of the checksum option is: The presence of the GUE security option is indicated in the SEC flag
bits of the GUE header.
The format of the security option is:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Payload coverage | | |
~ Security ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of the option are: The fields of the option are:
o Checksum: Computed checksum value. This checksum covers the GUE o Security (variable length). Contains the security information.
header (including fields and private data covered by Hlen), the The specific semantics and format of this field is expected to
GUE pseudo header, and optionally all or part of the payload be negotiated between the two communicating nodes.
(encapsulated packet).
o Payload coverage: Number of bytes of payload to cover in the To provide security capability, the SEC flags MUST be set. Different
checksum. Zero indicates that the checksum only covers the GUE sizes are allowed to allow different methods and extensibility. The
header and GUE pseudo header. If the value is greater than the use of the security field is expected to be negotiated out of band
encapsulated payload length, the packet must be dropped. between two tunnel end points.
3.2. Requirements The values in the SEC flags are:
The GUE header checksum must be set on transmit when using a zero UDP o 000b - No security field
checksum with IPv6.
The GUE header checksum must be set when the UDP checksum is zero for o 001b - 64 bit security field
IPv4 if the GUE header includes data that when corrupted can lead to
misdelivery or other serious consequences, and there is no other
mechanism that provides protection (no security field for instance).
Otherwise the GUE header checksum should be used with IPv4 when the
UDP checksum is zero.
The GUE header checksum should not be set when the UDP checksum is o 010b - 128 bit security field
non-zero. In this case the UDP checksum provides adequate protection
and this avoids convolutions when a packet traverses NAT that does
address translation (in that case the UDP checksum is required).
3.3. GUE checksum pseudo header o 011b - 256 bit security field
The GUE pseudo header checksum is included in the GUE checksum to o 100b - 388 bit security field (HMAC)
provide protection for the IP and UDP header elements which when
corrupted could lead to misdelivery of the GUE packet. The GUE pseudo
header checksum is similar to the standard IP pseudo header defined
in [RFC0768] and [RFC0793] for IPv4, and in [RFC2460] for IPv6.
The GUE pseudo header for IPv4 is: o 101b, 110b, 111b - Reserved values
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2. Usage
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source port | Destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The GUE pseudo header for IPv6 is: The GUE security field should be used to provide integrity and
authentication of the GUE header. Security parameters (interpretation
of security field, key management, etc.) are expected to be
negotiated out of band between two communicating hosts. Two security
algorithms are defined below.
3.3. Cookies
The security field may be used as a cookie. This would be similar to
the cookie mechanism described in L2TP [RFC3931], and the general
properties should be the same. A cookie may be used to validate the
encapsulation. The cookie is a shared value between an encapsulator
and decapsulator which should be chosen randomly and may be changed
periodically. Different cookies may used for logical flows between
the encapsulator and decapsulator, for instance packets sent with
different VNIDs in network virtualization [I.D.hy-nvo3-gue-4-nvo]
might have different cookies. Cookies may be 64, 128, or 256 bits in
size.
3.4. HMAC
Key-hashed message authentication code (HMAC) is a strong method of
checking integrity and authentication of data. This sections defines
a GUE security option for HMAC. Note that this is based on the HMAC
TLV description in "IPv6 Segment Routing Header (SRH)" [I.D.previdi-
6man-sr-header].
3.4.1. Extension field format
The HMAC option is a 288 bit field (36 octets). The security flags
are set to 100b to indicates the presence of a 288 bit security
field.
The format of the field is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | HMAC Key-id |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + ~ HMAC (256 bits) ~
| |
+ Destination Address +
| |
+ +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source port | Destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that the GUE pseudo header does not include payload length or
protocol as in the standard IP pseudo headers. The length field is
deemed unnecessary because:
o If the length is corrupted this will usually be detected by a Fields are:
checksum validation failure on the inner packet.
o Fragmentation of packets in a tunnel should occur on the inner
packet before being encapsulated or GUE fragmentation (section
4) may be performed at tunnel ingress. GUE packets are not
expected to be fragmented when using IPv6. See RFC6936 for
considerations of payload length and IPv6 checksum.
o A corrupted length field in itself should not lead to o HMAC Key-id: opaque field to allow multiple hash algorithms or
misdelivery of a packet. key selection
o Without the length field, the GUE pseudo header checksum is the o HMAC: Output of HMAC computation
same for all packets of flow. This is a useful property for
optimizations such as TCP Segment Offload (TSO).
3.4. Checksum computation The HMAC field is the output of the HMAC computation (per RFC 2104
[RFC2104]) using a pre-shared key identified by HMAC Key-id and of
the text which consists of the concatenation of:
The GUE checksum is computed and verified following the standard o The IP addresses
process for computing the Internet checksum [RFC1071]. Checksum
computation may be optimized per the mathematical properties
including parallel computation and incremental updates.
3.5. Transmitter operation o The GUE header including all private data and all optional
extensions that are present except for the security option
The procedure for setting the GUE checksum on transmit is: The purpose of the HMAC option is to verify the validity, the
integrity and the authorization of the GUE header itself.
1) Create the GUE header including the checksum and payload The HMAC Key-id field allows for the simultaneous existence of
coverage fields. The checksum field is initially set to zero. several hash algorithms (SHA-256, SHA3-256 ... or future ones) as
well as pre-shared keys. The HMAC Key-id field is opaque, i.e., it
has neither syntax nor semantic. Having an HMAC Key-id field allows
for pre-shared key roll-over when two pre-shared keys are supported
for a while GUE endpoints converge to a fresher pre-shared key.
2) Calculate the 1's complement checksum of the GUE header from 3.4.2. Selecting a hash algorithm
the start of the GUE header through the its length as indicated
in GUE Hlen.
3) Calculate the checksum of the GUE pseudo header for IPv4 or The HMAC field in the HMAC option is 256 bit wide. Therefore, the
IPv6. HMAC MUST be based on a hash function whose output is at least 256
bits. If the output of the hash function is 256, then this output is
simply inserted in the HMAC field. If the output of the hash function
is larger than 256 bits, then the output value is truncated to 256 by
taking the least-significant 256 bits and inserting them in the HMAC
field.
4) Calculate checksum of payload portion if payload coverage is GUE implementations can support multiple hash functions but MUST
enabled (payload coverage field is non-zero). If the length of implement SHA-2 [FIPS180-4] in its SHA-256 variant.
the payload coverage is odd, logically append a single zero
byte for the purposes of checksum calculation.
5) Add and fold the computed checksums for the GUE header, GUE 3.4.3. Pre-shared key management
pseudo header and payload coverage. Set the bitwise not of the
result in the GUE checksum field.
3.6. Receiver operation The field HMAC Key-id allows for:
If the GUE checksum option is present, the receiver must validate the o Key roll-over: when there is a need to change the key (the hash
checksum before processing any other fields or accepting the packet. pre-shared secret), then multiple pre-shared keys can be used
simultaneously. A decapsulator can have a table of <HMAC Key-
id, pre-shared secret> for the currently active and future keys.
The procedure for verifying the checksum is: o Different algorithms: by extending the previous table to <HMAC
Key-id, hash function, pre-shared secret>, the decapsulator can
also support simultaneously several hash algorithms (see section
Section 5.2.1)
1) If the payload coverage length is greater than the length of The pre-shared secret distribution can be done:
the encapsulated payload then drop the packet.
2) Calculate the checksum of the GUE header from the start of the o In the configuration of the endpoints
header to the end as indicated by Hlen.
3) Calculate the checksum of the appropriate GUE pseudo header. o Dynamically using a trusted key distribution such as [RFC6407]
4) Calculate the checksum of payload if payload coverage is The intent of this document is NOT to define yet-another-key-
enabled (payload coverage is non-zero). If the length of the distribution-protocol.
payload coverage is odd logically append a single zero byte for
the purposes of checksum calculation.
5) Sum the computed checksums for the GUE header, GUE pseudo 3.5. Interaction with other optional extensions
header, and payload coverage. If the result is all 1 bits (-0
in 1's complement arithmetic), the checksum is valid and the
packet is accepted; otherwise the checksum is considered
invalid and the packet must be dropped.
3.7. Security Considerations If GUE fragmentation (section 4) is used in concert with the GUE
security option, the security option processing is performed after
fragmentation at the encapsulator and before reassembly at the
decapsulator.
The checksum option is only a mechanism for corruption detection, it The GUE payload transform option (section 5) may be used in concert
is not a security mechanism. To provide integrity checks or with the GUE security option. The payload transform option could be
authentication of the GUE header, the GUE security option should be used to encrypt the GUE payload to provide privacy for an
used. encapsulated packet during transit. The security option provides
authentication and integrity for the GUE header (including the
payload transform field in the header). The two functions are
processed separately at tunnel end points. A GUE tunnel can use both
functions or use one of them. Section 5.3 details handling for when
both are used in a packet.
4. Fragmentation option 4. Fragmentation option
The fragmentation option allows an encapsulator to perform The fragmentation option allows an encapsulator to perform
fragmentation of packets being ingress to a tunnel. Procedures for fragmentation of packets being ingress to a tunnel. Procedures for
fragmentation and reassembly are defined in this section. This fragmentation and reassembly are defined in this section. This
specification adapts the procedures for IP fragmentation and specification adapts the procedures for IP fragmentation and
reassembly described in [RFC0791] and [RFC2460]. Fragmentation may be reassembly described in [RFC0791] and [RFC2460]. Fragmentation may be
performed on both data and control messages in GUE. performed on both data and control messages in GUE.
skipping to change at page 10, line 46 skipping to change at page 10, line 39
issues as that of normal IP fragmentation. Most significant of these issues as that of normal IP fragmentation. Most significant of these
is that the Identification field is only sixteen bits in IPv4 which is that the Identification field is only sixteen bits in IPv4 which
introduces problems with wraparound as described in [RFC4963]. introduces problems with wraparound as described in [RFC4963].
The second possibility follows the suggestion expressed in [RFC2764] The second possibility follows the suggestion expressed in [RFC2764]
and the fragmentation feature described in the AERO protocol and the fragmentation feature described in the AERO protocol
[I.D.templin-aerolink], that is for the tunneling protocol itself to [I.D.templin-aerolink], that is for the tunneling protocol itself to
incorporate a segmentation and reassembly capability that operates at incorporate a segmentation and reassembly capability that operates at
the tunnel level. In this method fragmentation is part of the the tunnel level. In this method fragmentation is part of the
encapsulation and an encapsulation header contains the information encapsulation and an encapsulation header contains the information
for reassembly. This is different from IP fragmentation in that the for reassembly. This differs from IP fragmentation in that the IP
IP headers of the original packet are not replicated for each headers of the original packet are not replicated for each fragment.
fragment.
Incorporating fragmentation into the encapsulation protocol has some Incorporating fragmentation into the encapsulation protocol has some
advantages: advantages:
o At least a 32 bit identifier can be defined to avoid issues of o At least a 32 bit identifier can be defined to avoid issues of
the 16 bit Identification in IPv4. the 16 bit Identification in IPv4.
o Encapsulation mechanisms for security and identification, such o Encapsulation mechanisms for security and identification, such
as virtual network identifiers, can be applied to each segment. as virtual network identifiers, can be applied to each segment.
skipping to change at page 11, line 28 skipping to change at page 11, line 20
4.2. Scope 4.2. Scope
This specification describes the mechanics of fragmentation in This specification describes the mechanics of fragmentation in
Generic UDP Encapsulation. The operational aspects and details for Generic UDP Encapsulation. The operational aspects and details for
higher layer implementation must be considered for deployment, but higher layer implementation must be considered for deployment, but
are considered out of scope for this document. The AERO protocol are considered out of scope for this document. The AERO protocol
[I.D.templin-aerolink] defines one use case of fragmentation with [I.D.templin-aerolink] defines one use case of fragmentation with
encapsulation. encapsulation.
4.3. Option format 4.3. Extension field format
The presence of the GUE fragmentation option is indicated by the F The presence of the GUE fragmentation option is indicated by the F
bit in the GUE header. bit in the GUE header.
The format of the fragmentation option is: The format of the fragmentation option is:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment offset |Res|M| Orig-proto | | | Fragment offset |Res|M| Orig-proto | |
skipping to change at page 12, line 8 skipping to change at page 11, line 48
fragment belongs. The fragment offset is measured in units of 8 fragment belongs. The fragment offset is measured in units of 8
octets (64 bits). The first fragment has offset zero. octets (64 bits). The first fragment has offset zero.
o Res: Two bit reserved field. Must be set to zero for o Res: Two bit reserved field. Must be set to zero for
transmission. If set to non-zero in a received packet then the transmission. If set to non-zero in a received packet then the
packet MUST be dropped. packet MUST be dropped.
o M: More fragments bit. Set to 1 when there are more fragments o M: More fragments bit. Set to 1 when there are more fragments
following in the datagram, set to 0 for the last fragment. following in the datagram, set to 0 for the last fragment.
o Orig-proto: The control type (when C bit is set) or the IP o Orig-proto: The control type (when C-bit is set) or the IP
protocol (when C bit is not set) of the fragmented packet. protocol (when C-bit is not set) of the fragmented packet.
o Identification: 40 bits. Identifies fragments of a fragmented o Identification: 40 bits. Identifies fragments of a fragmented
packet. packet.
Pertinent GUE header fields to fragmentation are: Pertinent GUE header fields to fragmentation are:
o C: This bit is set for each fragment based on the whether the o C-bit: This is set for each fragment based on the whether the
original packet being fragmented is a control or data message. original packet being fragmented is a control or data message.
o Proto/ctype - For the first fragment (fragment offset is zero) o Proto/ctype - For the first fragment (fragment offset is zero)
this is set to that of the original packet being fragmented this is set to that of the original packet being fragmented
(either will be a control type or IP protocol). For other (either will be a control type or IP protocol). For other
fragments, this is set to zero for a control message being fragments, this is set to zero for a control message being
fragmented, or to "No next header" (protocol number 59) for a fragmented, or to "No next header" (protocol number 59) for a
data message being fragmented. data message being fragmented.
o F bit - Set to indicate presence of the fragmentation option o F bit - Set to indicate presence of the fragmentation extension
field. field.
4.4. Fragmentation procedure 4.4. Fragmentation procedure
If an encapsulator determines that a packet must be fragmented (eg. If an encapsulator determines that a packet must be fragmented (eg.
the packet's size exceeds the Path MTU of the tunnel) it should the packet's size exceeds the Path MTU of the tunnel) it should
divide the packet into fragments and send each fragment as a separate divide the packet into fragments and send each fragment as a separate
GUE packet, to be reassembled at the decapsulator (tunnel egress). GUE packet, to be reassembled at the decapsulator (tunnel egress).
For every packet that is to be fragmented, the source node generates For every packet that is to be fragmented, the source node generates
skipping to change at page 13, line 23 skipping to change at page 13, line 17
+--------------+--------------+---------------+--//--+----------+ +--------------+--------------+---------------+--//--+----------+
| first | second | third | | last | | first | second | third | | last |
| fragment | fragment | fragment | .... | fragment | | fragment | fragment | fragment | .... | fragment |
+--------------+--------------+---------------+--//--+----------+ +--------------+--------------+---------------+--//--+----------+
Each fragment is encapsulated as the payload of a GUE packet. This is Each fragment is encapsulated as the payload of a GUE packet. This is
illustrated as: illustrated as:
+------------------+----------------+-----------------------+ +------------------+----------------+-----------------------+
| IP/UDP header | GUE header | first | | IP/UDP header | GUE header | first |
| header | w/ frag option | fragment | | | w/ frag option | fragment |
+------------------+----------------+-----------------------+ +------------------+----------------+-----------------------+
+------------------+----------------+-----------------------+ +------------------+----------------+-----------------------+
| IP/UDP header | GUE header | second | | IP/UDP header | GUE header | second |
| header | w/ frag option | fragment | | | w/ frag option | fragment |
+------------------+----------------+-----------------------+ +------------------+----------------+-----------------------+
o o
o o
+------------------+----------------+-----------------------+ +------------------+----------------+-----------------------+
| IP/UDP header | GUE header | last | | IP/UDP header | GUE header | last |
| header | w/ frag option | fragment | | | w/ frag option | fragment |
+------------------+----------------+-----------------------+ +------------------+----------------+-----------------------+
Each fragment packet is composed of: Each fragment packet is composed of:
(1) Outer IP and UDP headers as defined for GUE encapsulation. (1) Outer IP and UDP headers as defined for GUE encapsulation.
o The IP addresses and UDP destination port must be the same o The IP addresses and UDP ports must be the same for all
for all fragments of a fragmented packet. fragments of a fragmented packet.
o The source port selected for the inner flow identifier must
be the same value for all fragments of a fragmented packet.
(2) A GUE header that contains: (2) A GUE header that contains:
o The C bit which is set to the same value for all the o The C-bit which is set to the same value for all the
fragments of a fragmented packet based on whether a control fragments of a fragmented packet based on whether a control
message or data message was fragmented. message or data message was fragmented.
o A proto/ctype. In the first fragment this is set to the o A proto/ctype. In the first fragment this is set to the
value corresponding to the next header of the original value corresponding to the next header of the original
packet and will be either an IP protocol or a control type. packet and will be either an IP protocol or a control type.
For subsequent fragments, this field is set to 0 for a For subsequent fragments, this field is set to 0 for a
fragmented control message or 59 (no next header) for a fragmented control message or 59 (no next header) for a
fragmented data messages. fragmented data message.
o The F bit is set and fragment option is present. o The F bit is set and fragment extension field is present.
o Other GUE options. Note that options apply to the individual o Other GUE options. Note that options apply to the individual
GUE packet. For instance, the security option would be GUE packet. For instance, the security option would be
validated before reassembly. validated before reassembly.
(3) The GUE fragmentation option. The option contents include: (3) The GUE fragmentation option. The contents of the extension
field include:
o Orig-proto that identifies the first header of the original o Orig-proto specifies the protocol of the original packet.
packet.
o A Fragment Offset containing the offset of the fragment, in o A Fragment Offset containing the offset of the fragment, in
8-octet units, relative to the start of the of the original 8-octet units, relative to the start of the of the original
packet. The Fragment Offset of the first ("leftmost") packet. The Fragment Offset of the first ("leftmost")
fragment is 0. fragment is 0.
o An M flag value of 0 if the fragment is the last o An M flag value of 0 if the fragment is the last
("rightmost") one, else an M flag value of 1. ("rightmost") one, else an M flag value of 1.
o The Identification value generated for the original packet. o The Identification value generated for the original packet.
skipping to change at page 14, line 49 skipping to change at page 14, line 40
+-------------------------------//------------------------------+ +-------------------------------//------------------------------+
| Original packet | | Original packet |
| (e.g. an IPv4, IPv6, Ethernet packet) | | (e.g. an IPv4, IPv6, Ethernet packet) |
+------------------------------//-------------------------------+ +------------------------------//-------------------------------+
The following rules govern reassembly: The following rules govern reassembly:
The IP/UDP/GUE headers of each packet are retained until all The IP/UDP/GUE headers of each packet are retained until all
fragments have arrived. The reassembled packet is then composed fragments have arrived. The reassembled packet is then composed
of the decapsulated payloads in the GUE fragments, and the of the decapsulated payloads in the GUE packets, and the
IP/UDP/GUE headers are discarded. IP/UDP/GUE headers are discarded.
When a GUE packet is received with the fragment option, the When a GUE packet is received with the fragment extension, the
proto/ctype in the GUE header must be validated. In the case proto/ctype field in the GUE header must be validated. In the
that the packet is a first fragment (fragment offset is zero), case that the packet is a first fragment (fragment offset is
the proto/ctype in the GUE header must equal the orig-proto zero), the proto/ctype in the GUE header must equal the orig-
value in the fragmentation option. For subsequent fragments proto value in the fragmentation option. For subsequent
(fragment offset is non-zero) the proto/ctype in the GUE header fragments (fragment offset is non-zero) the proto/ctype in the
must be 0 for a control message or 59 (no-next-hdr) for a data GUE header must be 0 for a control message or 59 (no-next-hdr)
message. If the proto/ctype value is invalid then for a received for a data message. If the proto/ctype value is invalid for a
packet it MUST be dropped. received packet it MUST be dropped.
An original packet is reassembled only from GUE fragment packets An original packet is reassembled only from GUE fragment packets
that have the same outer Source Address, Destination Address, that have the same outer source address, destination address,
UDP source port, UDP destination port, GUE header C bit, virtual UDP source port, UDP destination port, GUE header C-bit, virtual
network identifier if present, orig-proto value in the network identifier if present, orig-proto value in the
fragmentation option, and Fragment Identification. The protocol fragmentation option, and Fragment Identification. The protocol
type or control message type (depending on the C bit) for the type or control message type (depending on the C-bit) for the
reassembled packet is the value of the GUE header proto/ctype reassembled packet is the value of the GUE header proto/ctype
field in the first fragment. field in the first fragment.
The following error conditions may arise when reassembling fragmented The following error conditions may arise when reassembling fragmented
packets with GUE encapsulation: packets with GUE encapsulation:
If insufficient fragments are received to complete reassembly of If insufficient fragments are received to complete reassembly of
a packet within 60 seconds (or a configurable period) of the a packet within 60 seconds (or a configurable period) of the
reception of the first-arriving fragment of that packet, reception of the first-arriving fragment of that packet,
reassembly of that packet must be abandoned and all the reassembly of that packet must be abandoned and all the
skipping to change at page 15, line 44 skipping to change at page 15, line 34
If the payload length of a fragment is not a multiple of 8 If the payload length of a fragment is not a multiple of 8
octets and the M flag of that fragment is 1, then that fragment octets and the M flag of that fragment is 1, then that fragment
must be discarded. must be discarded.
If the length and offset of a fragment are such that the payload If the length and offset of a fragment are such that the payload
length of the packet reassembled from that fragment would exceed length of the packet reassembled from that fragment would exceed
65,535 octets, then that fragment must be discarded. 65,535 octets, then that fragment must be discarded.
If a fragment overlaps another fragment already saved for If a fragment overlaps another fragment already saved for
reassembly then the new fragment that overlaps the existing reassembly then the new fragment that overlaps the existing
fragment MUST be discarded fragment MUST be discarded.
If the first fragment is too small then it is possible that it If the first fragment is too small then it is possible that it
does not contain the necessary headers for a stateful firewall. does not contain the necessary headers for a stateful firewall.
Sending small fragments like this has been used as an attack on Sending small fragments like this has been used as an attack on
IP fragmentation. To mitigate this problem, an implementation IP fragmentation. To mitigate this problem, an implementation
should ensure that the first fragment contains the headers of should ensure that the first fragment contains the headers of
the encapsulated packet at least through the transport header. the encapsulated packet at least through the transport header.
A GUE node must be able to accept a fragmented packet that, A GUE node must be able to accept a fragmented packet that,
after reassembly and decapsulation, is as large as 1500 octets. after reassembly and decapsulation, is as large as 1500 octets.
skipping to change at page 16, line 25 skipping to change at page 16, line 15
4.6. Security Considerations 4.6. Security Considerations
Exploits that have been identified with IP fragmentation are Exploits that have been identified with IP fragmentation are
conceptually applicable to GUE fragmentation. conceptually applicable to GUE fragmentation.
Attacks on GUE fragmentation can be mitigated by: Attacks on GUE fragmentation can be mitigated by:
o Hardened implementation that applies applicable techniques from o Hardened implementation that applies applicable techniques from
implementation of IP fragmentation. implementation of IP fragmentation.
o Application of GUE security (section 5) or IPsec [RFC4301]. o Application of GUE security (section 3) or IPsec [RFC4301].
Security mechanisms can prevent spoofing of fragments from Security mechanisms can prevent spoofing of fragments from
unauthorized sources. unauthorized sources.
o Implement fragment filter techniques for GUE encapsulation as o Implement fragment filter techniques for GUE encapsulation as
described in [RFC1858] and [RFC3128]. described in [RFC1858] and [RFC3128].
o Do not accepted data in overlapping segments. o Do not accepted data in overlapping segments.
o Enforce a minimum size for the first fragment. o Enforce a minimum size for the first fragment.
5. Security and payload transform options 5. Payload transform option
The security option and the payload transform option are used to
provide security for the GUE headers and payload. The GUE security
option provides origin authentication and integrity protection of the
GUE header at tunnel end points to guarantee isolation between
tunnels and mitigate Denial of Service attacks. The payload transform
option provides a means to perform encryption and authentication of
the GUE packet that protects the payload from eavesdropping,
tampering, or message forgery.
5.1. Security option format
The presence of the GUE security option is indicated in the SEC flag
bits of the GUE header.
The format of the fragmentation option is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of the option are:
o Security (8, 16, or 32 octets). Contains the security
information. The specific semantics and format of this field is
expected to be negotiated between the two communicating nodes.
To provide security capability, the SEC flags MUST be set. Different
sizes are allowed to provide different methods and extensibility. The
use of the security field is expected to be negotiated out of band
between two tunnel end points.
The possible values in the SEC flags are:
o 00 - No security field
o 01 - 64 bit security field
o 10 - 128 bit security field
o 11 - 256 bit security field
5.2. Security option usage
The GUE security field should be used to provide integrity and
authentication of the GUE header. Security negotiation
(interpretation of security field, key management, etc.) is expected
to be negotiated out of band between two communicating hosts. Two
possible uses for this field are outlined below, a more precise
specification is deferred to other documents.
5.2.1. Cookies
The security field may be used as a cookie. This would be similar to
cookie mechanism described in L2TP [RFC3931], and the general
properties should be the same. The cookie may be used to validate the
encapsulation. The cookie is a shared value between an encapsulator
and decapsulator which should be chosen randomly and may be changed
periodically. Different cookies may used for logical flows between
the encapsulator and decapsulator, for instance packets sent with
different VNIs in network virtualization [I.D.hy-nvo3-gue-4-nvo]
might have different cookies.
5.2.2. Secure hash
Strong authentication of the GUE header can be provided using a The payload transform option indicates that the GUE payload has been
secure hash. This may follow the model of the TCP authentication transformed. Transforming a payload is done by running a function
option [RFC5925]. In this case the security field holds a message over the data and possibly modifying it (encrypting it for instance).
digest for the GUE header (e.g. 16 bytes from MD5). The digest might The payload transform option indicates the method used to transform
be done over static fields in IP and UDP headers per negotiation the data so that a decapsulator is able to validate and reverse the
(addresses, ports, and protocols). In order to provide enough transformation to recover the original data. Payload transformations
entropy, a random salt value in each packet might be added, for could include encryption, authentication, CRC coverage, and
instance the security field could be a 256 bit value that contains compression. This specification defines a transformation for DTLS.
128 bits of salt value, and a 128 bit digest value. The use of secure
hashes requires shared keys which are presumably negotiated and
rotated as needed out of band.
5.3. Payload Transform Option format 5.1. Extension field format
The presence of the GUE payload transform option is indicated by the The presence of the GUE payload transform option is indicated by the
T bit in the GUE header. T bit in the GUE header.
The format of Payload Transform Field is: The format of Payload Transform Field is:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Payload Type | Reserved | | Type | P_C_type | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of the option are: The fields of the option are:
Type: Payload Transform Type or Code point. Each payload transform Type: Payload Transform Type or Code point. Each payload transform
mechanism must have one code point registered in IANA. This mechanism must have one code point registered in IANA. This
document specifies: document specifies:
0x01: for DTLS [RFC6347] 0x01: for DTLS [RFC6347]
0x80~0xFF: for private payload transform types 0x80~0xFF: for private payload transform types
A private payload transform type can be used for A private payload transform type can be used for
experimental purpose or vendor proprietary mechanisms. experimental purpose or vendor proprietary mechanisms.
Payload Type: Indicates the encrypted payload type. When payload P_C_type: Indicates the protocol or control type of the
transform option is present, proto/ctype in the base header untransformed payload. When payload transform option is
should set to 59 ("No next header") for a data message and present, proto/ctype in the GUE header should set to 59 ("No
zero for a control message. The payload type (IP protocol or next header") for a data message and zero for a control
control message type) of the unencrypted payload must be message. The IP protocol or control message type of the
encoded in this field. untransformed payload must be encoded in this field.
The benefit of this rule is to prevent a middle box from The benefit of this rule is to prevent a middle box from
inspecting the encrypted payload according to GUE next inspecting the encrypted payload according to GUE next
protocol. The assumption here is that a middle box may protocol. The assumption here is that a middle box may
understand GUE base header but does not understand GUE understand GUE base header but does not understand GUE
option flag definitions. option flag definitions.
Reserved field for DTLS type MUST set to Zero. For other Data: A field that can be set according to the requirements of
transformation types, the use of reserved field may be specified. each payload transform type. If the specification for a
payload transform type does not specify how this field is to
be set, then the field MUST be set to zero.
5.3.1. Payload transform option usage 5.2. Usage
The payload transform option provides a mechanism to transform or The payload transform option provides a mechanism to transform or
interpret the payload of a GUE packet. The Type field describes the interpret the payload of a GUE packet. The Type field provides the
format of the payload before transformation and Payload Type provides method used to transform the payload, and the P_C_type field provides
the protocol of the packet after transformation. The payload the protocol or control message type of the of payload before being
transformation option is generic so that it can have both security transformed. The payload transformation option is generic so that it
related uses (such as DTLS) as well as non security related uses can have both security related uses (such as DTLS) as well as non
(such as compression, CRC, etc.). security related uses (such as compression, CRC, etc.).
An encapsulator performs payload transformation before transmission,
and a decapsulator must perform the reverse transformation before
accepting a packet. For example, if an encapsulator transforms a
payload by encrypting it, the peer decaspsulator must decrypt the
payload before accepting the packet. If a decapsulator fails to
perform the reverse transformation or cannot validate the
transformation it MUST discard the packet and MAY generate an alert
to the management system.
5.3. Interaction with other optional extensions
If GUE fragmentation (section 4) is used in concert with the GUE
transform option, the transform option processing is performed after
fragmentation at the encapsulator and before reassembly at the
decapsulator. If the payload transform changes the size of the data
being fragmented this must be taken into account during
fragmentation.
If both the security option and the payload transform are used in a
GUE packet, an encapsulator must perform the payload transformation
first, set the payload transform option in the GUE header, and then
create the security option. A decapsulator does processing in
reverse-- the security option is processed (GUE header is validated)
and then the reverse payload transform is performed.
In order to get flow entropy from the payload, an encapsulator should
derive the flow entropy before performing a payload transform.
5.4. DTLS transform
The payload of a GUE packet can be secured using Datagram Transport The payload of a GUE packet can be secured using Datagram Transport
Layer Security [RFC6347]. An encapsulator would apply DTLS to the GUE Layer Security [RFC6347]. An encapsulator would apply DTLS to the GUE
payload so that the payload packets are encrypted and the GUE header payload so that the payload packets are encrypted and the GUE header
remains in plaintext. The payload transform option is set to indicate remains in plaintext. The payload transform option is set to indicate
that the payload should be interpreted as a DTLS record. that the payload should be interpreted as a DTLS record.
5.4. Operation of security mechanisms The payload transform option for DLTS is:
GUE secure transport mechanisms apply to both IPv4 and IPv6 underlay
networks. The outer IP address MUST be tunnel egress IP address (dst)
and tunnel ingress IP address (src). The GUE security option provides
origin authentication and integrity to GUE based tunnel; GUE payload
encryption provides payload privacy over an IP delivery network or
Internet. The two functions are processed separately at tunnel end
points. A GUE tunnel can use both functions or use one of them.
When both encryption and security are required, an encapsulator must
perform payload encryption first and then encapsulate the encrypted
packet with security flag and payload transform flag set in GUE
header; the security option field must be filled according Section
5.2 above and the payload transform field must be filled according to
Section 5.3 above. The decapsulator must decapsulate the packet
first, then perform the authentication validation. If the validation
is successful, it performs the payload decryption according to the
encryption information in the payload encryption field in the header.
Else if the validation fails, the decapsulator must discard the
packet and may generate an alert to the management system. These
processing rules also apply when only one function, either encryption
or security, is enabled, except the other function is not performed
as stated above.
If GUE fragmentation is used in concert with the GUE security option
and/or payload transform option, the security and playload
transformation are performed after fragmentation at the encapsulator
and before reassembly at the decapsulator.
In order to get flow entropy from the payload, an encapsulator must +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
determine the flow entropy value (e.g. a hash over the 4-tuple of a | 1 | P_C_type | 0 |
TCP connection) before performing the payload encryption. The flow +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
entropy value can then be set in UDP src port of the GUE packet.
DTLS [RFC6347] provides packet fragmentation capability. To avoid DTLS [RFC6347] provides packet fragmentation capability. To avoid
packets fragmentation being performed multiple times by an packet fragmentation performed multiple times, a GUE encapsulator
encapsulator, an encapsulator SHOULD only perform the packet SHOULD only perform the packet fragmentation at packet encapsulation
fragmentation at part of the packet encapsulation process (e.g. using process, i.e., not in payload encryption process.
the GUE fragmentation option), not in payload encryption process
(i.e. DTLS layer fragmentation should be avoided).
DTLS usage [RFC6347] is limited to a single DTLS session for any DTLS usage [RFC6347] is limited to a single DTLS session for any
specific tunnel encapsulator/decapsulator pair (identified by source specific tunnel encapsulator/decapsulator pair (identified by source
and destination IP addresses). Both IP addresses MUST be unicast and destination IP addresses). Both IP addresses MUST be unicast
addresses - multicast traffic is not supported when DTLS is used. A addresses - multicast traffic is not supported when DTLS is used. A
GUE tunnel decapsulator implementation that supports DTLS can GUE tunnel decapsulator implementation that supports DTLS can
establish DTLS session(s) with one or multiple tunnel encapsulators, establish DTLS session(s) with one or multiple tunnel encapsulators,
and likewise a GUE tunnel encapsulator implementation can establish and likewise a GUE tunnel encapsulator implementation can establish
DTLS session(s) with one or multiple decapsulators. DTLS session(s) with one or multiple decapsulators.
5.5. Considerations of Using Other Security Tunnel Mechanisms
GUE may rely on other secure tunnel mechanisms such as DTLS [RFC6347]
over the whole UDP payload for securing the whole GUE packet or IPsec
[RFC4301] to achieve the secure transport over an IP network or
Internet.
IPsec [RFC4301] was designed as a network security mechanism, and
therefore it resides at the network layer. As such, if the tunnel is
secured with IPsec, the UDP header would not be visible to
intermediate routers anymore in either IPsec tunnel or transport
mode. The big drawback here prohibits intermediate routers to perform
load balancing based on the flow entropy in UDP header. In addition,
this method prohibits any middle box function on the path.
By comparison, DTLS [RFC6347] was designed with application security
and can better preserve network and transport layer protocol
information than IPsec [RFC4301]. Using DTLS to secure the GUE
tunnel, both GUE header and payload will be encrypted. In order to
differentiate plaintext GUE header from encrypted GUE header, the
destination port of the UDP header between two must be different,
which essentially requires another standard UDP port for GUE with
DTLS. The drawback on this method is to prevent a middle box
operation to GUE tunnel on the path.
Use of two independent tunnel mechanisms such as GUE and DTLS to
carry a network protocol over an IP network adds some overlap and
process complex. For example, fragmentation will be done twice.
As the result, a GUE tunnel SHOULD use the security mechanisms
specified in this document to provide secure transport over an IP
network or Internet when it is needed. GUE tunnels with the GUE
security options can be used as a secure transport mechanism over an
IP network and Internet.
6. Remote checksum offload option 6. Remote checksum offload option
Remote checksum offload is mechanism that provides checksum offload Remote checksum offload is mechanism that provides checksum offload
of encapsulated packets using rudimentary offload capabilities found of encapsulated packets using rudimentary offload capabilities found
in most Network Interface Card (NIC) devices. Many NIC in most Network Interface Card (NIC) devices. Many NIC
implementations can only offload the outer UDP checksum in UDP implementations can only offload the outer UDP checksum in UDP
encapsulation. Remote checksum offload is described in [UDPENCAP]. encapsulation. Remote checksum offload is described in [UDPENCAP].
In remote checksum offload the outer header checksum, that is in the In remote checksum offload the outer header checksum, that in the
outer UDP header, is enabled in packets and, with some additional outer UDP header, is enabled in packets and, with some additional
meta information, a receiver is able to deduce the checksum to be set meta information, a receiver is able to deduce the checksum to be set
for an inner encapsulated packet. Effectively this offloads the for an inner encapsulated packet. Effectively this offloads the
computation of the inner checksum. Enabling the outer checksum in computation of the inner checksum. Enabling the outer checksum in
encapsulation has the additional advantage that it covers more of the encapsulation has the additional advantage that it covers more of the
packet than the inner checksum including the encapsulation headers. packet than the inner checksum including the encapsulation headers.
The remote offload checksum option should not be used when GUE 6.1. Extension field format
fragmentation is also being performed. In this case the offload of
the outer UDP checksum does not cover the whole transport segment so
remote checksum offload would not properly set the inner transport
layer checksum.
6.1. Option format
The presence of the GUE remote checksum offload option is indicated The presence of the GUE remote checksum offload option is indicated
by the R bit in the GUE header. by the R bit in the GUE header.
The format of remote checksum offload field is: The format of remote checksum offload field is:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum start | Checksum offset | | Checksum start | Checksum offset |
skipping to change at page 22, line 4 skipping to change at page 19, line 27
The presence of the GUE remote checksum offload option is indicated The presence of the GUE remote checksum offload option is indicated
by the R bit in the GUE header. by the R bit in the GUE header.
The format of remote checksum offload field is: The format of remote checksum offload field is:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum start | Checksum offset | | Checksum start | Checksum offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of the option are: The fields of the option are:
o Checksum start: starting offset for checksum computation o Checksum start: starting offset for checksum computation
relative to the start of the encapsulated payload. This is relative to the start of the encapsulated payload. This is
typically the offset of a transport header (e.g. UDP or TCP). typically the offset of a transport header (e.g. UDP or TCP).
o Checksum offset: Offset relative to the start of the o Checksum offset: Offset relative to the start of the
encapsulated packet where the derived checksum value is to be encapsulated packet where the derived checksum value is to be
written. This typically is the offset of the checksum field in written. This typically is the offset of the checksum field in
the transport header (e.g. UDP or TCP). the transport header (e.g. UDP or TCP).
6.2. Transmitter operation 6.2. Usage
The typical actions to set remote checksum offload on transmit 6.2.1. Transmitter operation
are:
The typical actions to set remote checksum offload on transmit are:
1) Transport layer creates a packet and indicates in internal 1) Transport layer creates a packet and indicates in internal
packet meta data that checksum is to be offloaded to the NIC packet meta data that checksum is to be offloaded to the NIC
(normal transport layer processing for checksum offload). The (normal transport layer processing for checksum offload). The
checksum field is populated with the bitwise not of the checksum field is populated with the bitwise not of the
checksum of the pseudo header or zero as appropriate. checksum of the pseudo header or zero as appropriate.
2) Encapsulation layer adds its headers to the packet including 2) Encapsulation layer adds its headers to the packet including
the offload meta data. The start offset and checksum offset are the remote checksum offload option. The start offset and
set accordingly. checksum offset are set accordingly.
3) Encapsulation layer arranges for checksum offload of the outer 3) Encapsulation layer arranges for checksum offload of the outer
header checksum (e.g. UDP). header checksum (e.g. UDP).
4) Packet is sent to the NIC. The NIC will perform transmit 4) Packet is sent to the NIC. The NIC will perform transmit
checksum offload and set the checksum field in the outer checksum offload and set the checksum field in the outer
header. The inner header and rest of the packet are transmitted header. The inner header and rest of the packet are transmitted
without modification. without modification.
6.3. Receiver operation 6.2.2. Receiver operation
The typical actions a host receiver does to support remote checksum The typical actions a host receiver does to support remote checksum
offload are: offload are:
1) Receive packet and validate outer checksum following normal 1) Receive packet and validate outer checksum following normal
processing (e.g. validate non-zero UDP checksum). processing (e.g. validate non-zero UDP checksum).
2) Validate the checksum option. If checksum start is greater than 2) Validate the remote checksum option. If checksum start is
the length of the packet, then the packet must be dropped. If greater than the length of the packet, then the packet MUST be
checksum offset is greater then the length of the packet minus dropped. If checksum offset is greater then the length of the
two, then the packet must be dropped. packet minus two, then the packet MUST be dropped.
3) Deduce full checksum for the IP packet. If a NIC is capable of 3) Deduce full checksum for the IP packet. If a NIC is capable of
receive checksum offload it will return either the full receive checksum offload it will return either the full
checksum of the received packet or an indication that the UDP checksum of the received packet or an indication that the UDP
checksum is correct. Either of these methods can be used to checksum is correct. Either of these methods can be used to
deduce the checksum over the IP packet [UDPENCAP]. deduce the checksum over the IP packet [UDPENCAP].
4) From the packet checksum, subtract the checksum computed from 4) From the packet checksum, subtract the checksum computed from
the start of the packet (outer IP header) to the offset in the the start of the packet (outer IP header) to the offset in the
packet indicted by checksum start in the meta data. The result packet indicted by checksum start in the meta data. The result
skipping to change at page 23, line 28 skipping to change at page 21, line 5
header) to the end of the packet header) to the end of the packet
start_of_packet: address of start of packet start_of_packet: address of start of packet
encap_payload_offset: relative to start_of_packet encap_payload_offset: relative to start_of_packet
csum_start: value from meta data csum_start: value from meta data
checksum(start, len): function to compute checksum from start checksum(start, len): function to compute checksum from start
address for len bytes address for len bytes
csum -= checksum(start_of_packet, encap_payload_offset + csum -= checksum(start_of_packet, encap_payload_offset +
csum_start) csum_start)
4) Write the resultant checksum value into the packet at the 5) Write the resultant checksum value into the packet at the
offset provided by checksum offset in the meta data. offset provided by checksum offset in the meta data.
In pseudo code: In pseudo code:
csum_offset: offset of checksum field csum_offset: offset of checksum field
*(start_of_packet + encap_payload_offset + *(start_of_packet + encap_payload_offset +
csum_offset) = csum csum_offset) = csum
5) Checksum is verified at the transport layer using normal 6) Checksum is verified at the transport layer using normal
processing. This should not require any checksum computation processing. This should not require any checksum computation
over the packet since the complete checksum has already been over the packet since the complete checksum has already been
provided. provided.
6.4. Security Considerations 6.3. Security Considerations
Remote checksum offload allows a means to change the GUE payload Remote checksum offload allows a means to change the GUE payload
before being received at a decapsulator. In order to prevent misuse before being received at a decapsulator. In order to prevent misuse
of this mechanism, a decapsulator should apply security checks on the of this mechanism, a decapsulator should apply security checks on the
GUE payload only after checksum remote offload has been processed. GUE payload only after checksum remote offload has been processed.
7. Processing order of options 7. Checksum option
The GUE checksum option provides a checksum that covers the GUE
header, a GUE pseudo header, and optionally part or all of the GUE
payload. The GUE pseudo header includes the corresponding IP
addresses as well as the UDP ports of the encapsulating headers. This
checksum should provide adequate protection against address
corruption in IPv6 when the UDP checksum is zero. Additionally, the
GUE checksum provides protection of the GUE header when the UDP
checksum is set to zero with either IPv4 or IPv6. In particular, the
GUE checksum can provide protection for some sensitive data, such as
the virtual network identifier ([I.D.hy-nvo3-gue-4-nvo]), which when
corrupted could lead to mis-delivery of a packet to the wrong virtual
network.
7.1. Extension field format
The presence of the GUE checksum option is indicated by the K bit in
the GUE header.
The format of the checksum extension is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Payload coverage |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of the option are:
o Checksum: Computed checksum value. This checksum covers the GUE
header (including fields and private data covered by Hlen), the
GUE pseudo header, and optionally all or part of the payload
(encapsulated packet).
o Payload coverage: Number of bytes of payload to cover in the
checksum. Zero indicates that the checksum only covers the GUE
header and GUE pseudo header. If the value is greater than the
encapsulated payload length, the packet must be dropped.
7.2. Requirements
The GUE header checksum should be set on transmit when using a zero
UDP checksum with IPv6.
The GUE header checksum should be used when the UDP checksum is zero
for IPv4 if the GUE header includes data that when corrupted can lead
to misdelivery or other serious consequences, and there is no other
mechanism that provides protection (no security field that checks
integrity for instance).
The GUE header checksum should not be set when the UDP checksum is
non-zero. In this case the UDP checksum provides adequate protection
and this avoids convolutions when a packet traverses NAT that does
address translation (in that case the UDP checksum is required).
7.3. GUE checksum pseudo header
The GUE pseudo header checksum is included in the GUE checksum to
provide protection for the IP and UDP header elements which when
corrupted could lead to misdelivery of the GUE packet. The GUE pseudo
header checksum is similar to the standard IP pseudo header defined
in [RFC0768] and [RFC0793] for IPv4, and in [RFC2460] for IPv6.
The GUE pseudo header for IPv4 is:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source port | Destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The GUE pseudo header for IPv6 is:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source port | Destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that the GUE pseudo header does not include payload length or
protocol as in the standard IP pseudo headers. The length field is
deemed unnecessary because:
o If the length is corrupted this will usually be detected by a
checksum validation failure on the inner packet.
o Fragmentation of packets in a tunnel should occur on the inner
packet before being encapsulated or GUE fragmentation (section
4) may be performed at tunnel ingress. GUE packets are not
expected to be fragmented when using IPv6. See RFC6936 for
considerations of payload length and IPv6 checksum.
o A corrupted length field in itself should not lead to
misdelivery of a packet.
o Without the length field, the GUE pseudo header checksum is the
same for all packets of flow. This is a useful property for
optimizations such as TCP Segment Offload (TSO).
7.4. Usage
The GUE checksum is computed and verified following the standard
process for computing the Internet checksum [RFC1071]. Checksum
computation may be optimized per the mathematical properties
including parallel computation and incremental updates.
7.4.1. Transmitter operation
The procedure for setting the GUE checksum on transmit is:
1) Create the GUE header including the checksum and payload
coverage fields. The checksum field is initially set to zero.
2) Calculate the 1's complement checksum of the GUE header from
the start of the GUE header through the its length as indicated
in GUE Hlen.
3) Calculate the checksum of the GUE pseudo header for IPv4 or
IPv6.
4) Calculate checksum of payload portion if payload coverage is
enabled (payload coverage field is non-zero). If the length of
the payload coverage is odd, logically append a single zero
byte for the purposes of checksum calculation.
5) Add and fold the computed checksums for the GUE header, GUE
pseudo header and payload coverage. Set the bitwise not of the
result in the GUE checksum field.
7.4.2.Receiver operation
If the GUE checksum option is present, the receiver must validate the
checksum before processing any other fields or accepting the packet.
The procedure for verifying the checksum is:
1) If the payload coverage length is greater than the length of
the encapsulated payload then drop the packet.
2) Calculate the checksum of the GUE header from the start of the
header to the end as indicated by Hlen.
3) Calculate the checksum of the appropriate GUE pseudo header.
4) Calculate the checksum of payload if payload coverage is
enabled (payload coverage is non-zero). If the length of the
payload coverage is odd logically append a single zero byte for
the purposes of checksum calculation.
5) Sum and fold the computed checksums for the GUE header, GUE
pseudo header, and payload coverage. If the result is all 1
bits (-0 in 1's complement arithmetic), the checksum is valid
and the packet is accepted; otherwise the checksum is
considered invalid and the packet must be dropped.
7.5. Security Considerations
The checksum option is only a mechanism for corruption detection, it
is not a security mechanism. To provide integrity checks or
authentication of the GUE header, the GUE security option should be
used.
8. Processing order of options
Options must be processed in a specific order for both sending and Options must be processed in a specific order for both sending and
receive. Note that some options, such as the checksum option, depend receive.
on other fields in the GUE header to be set.
The order of processing options to send a GUE packet are: The order of processing options to send a GUE packet are:
1) Set VNID option. 1) Set VNID option.
2) Fragment if necessary and set fragmentation option. VNID is 2) Fragment if necessary and set fragmentation option. VNID is
copied into each fragment. Note that if payload transformation copied into each fragment. Note that if payload transformation
will increase the size of the payload that must be accounted will increase the size of the payload that must be accounted
for when deciding how to fragment for when deciding how to fragment
3) Set Remote checksum offload. 3) Perform payload transform (potentially on a fragment) and set
payload transform option.
4) Perform payload transform (potentially on each fragment) and 4) Set Remote checksum offload.
set payload transform option.
5) Set security option. 5) Set security option.
6) Calculate GUE checksum and set checksum option. 6) Calculate GUE checksum and set checksum option.
On reception the order of actions is reversed. On reception the order of actions is reversed.
1) Verify GUE checksum. 1) Verify GUE checksum.
2) Verify security option. 2) Verify security option.
3) Perform payload transformation (i.e. decrypt payload) 3) Adjust packet for remote checksum offload.
4) Adjust packet for remote checksum offload. 4) Perform payload transformation (i.e. decrypt payload)
5) Perform reassembly. 5) Perform reassembly.
6) Receive on virtual network indicated by VNID. 6) Receive on virtual network indicated by VNID.
Note that the relative processing order of private fields is Note that the relative processing order of private fields is
unspecified. unspecified.
8. Security Considerations 9. Security Considerations
Encapsulation of network protocol in GUE should not increase security
risk, nor provide additional security in itself. GUE requires that
the source port for UDP packets should be randomly seeded to mitigate
some possible denial service attacks.
If the integrity and privacy of data packets being transported If the integrity and privacy of data packets being transported
through GUE is a concern, GUE security and payload encryption SHOULD through GUE is a concern, GUE security option and payload encryption
be used to remove the concern. If the integrity is the only concern, using the the transform option SHOULD be used to remove the concern.
the tunnel may consider use of GUE security only for optimization. If the integrity is the only concern, the tunnel may consider use of
Likewise, if the privacy is the only concern, the tunnel may use GUE GUE security only for optimization. Likewise, if the privacy is the
encryption function only. only concern, the tunnel may use GUE encryption function only.
If GUE payload already provides secure mechanism, e.g., the payload If GUE payload already provides secure mechanism, e.g., the payload
is IPsec packets, it is still valuable to consider use of GUE is IPsec packets, it is still valuable to consider use of GUE
security. security.
9. IANA Consideration GUE may rely on other secure tunnel mechanisms such as DTLS [RFC6347]
over the whole UDP payload for securing the whole GUE packet or IPsec
[RFC4301] to achieve the secure transport over an IP network or
Internet.
IPsec [RFC4301] was designed as a network security mechanism, and
therefore it resides at the network layer. As such, if the tunnel is
secured with IPsec, the UDP header would not be visible to
intermediate routers in either IPsec tunnel or transport mode. The
big drawback here prohibits intermediate routers to perform load
balancing based on the flow entropy in UDP header. In addition, this
method prohibits any middle box function on the path.
By comparison, DTLS [RFC6347] was designed with application security
and can better preserve network and transport layer protocol
information than IPsec [RFC4301]. Using DTLS over UDP to secure the
GUE tunnel, both GUE header and payload will be encrypted. In order
to differentiate plaintext GUE header from encrypted GUE header, the
destination port of the UDP header between two must be different,
which essentially requires another standard UDP port for GUE with
DTLS. The drawback on this method is to prevent a middle box
operation to GUE tunnel on the path.
Use of two independent tunnel mechanisms such as GUE and DTLS over
UDP to carry a network protocol over an IP network adds some overlap
and complexity. For example, fragmentation will be done twice.
As the result, a GUE tunnel SHOULD use the security mechanisms
specified in this document to provide secure transport over an IP
network or Internet when it is needed. GUE encapsulation can be used
as a secure transport mechanism over an IP network and Internet.
10. IANA Consideration
IANA is requested to assign flags for the extensions defined in this IANA is requested to assign flags for the extensions defined in this
specification. Specifically, an assignment is requested for the V, specification. Specifically, an assignment is requested for the V,
SEC, K, F, T and R flags in the "GUE flag-fields" registry (proposed SEC, F, T, R, and K flags in the "GUE flag-fields" registry (proposed
in [I.D.nvo3-gue]). in [I.D.nvo3-gue]).
10. References IANA is requested to set up a registry for the GUE payload transform
types. Payload transform types are 8 bit values. New values for
control types 1-127 are assigned via Standards Action [RFC5226].
10.1. Normative References +----------------+------------------+---------------+
| Transform type | Description | Reference |
+----------------+------------------+---------------+
| 0 | Reserved | This document |
| | | |
| 1 | DTLS | This document |
| | | |
| 2..127 | Unassigned | |
| | | |
| 128..255 | User defined | This document |
+----------------+------------------+---------------+
11. References
11.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981. 1981.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[I.D.nvo3-gue] T. Herbert, L. Yong, and O. Zia, "Generic UDP [I.D.nvo3-gue] T. Herbert, L. Yong, and O. Zia, "Generic UDP
Encapsulation" draft-ietf-nvo3-gue-03 Encapsulation" draft-ietf-nvo3-gue-03
10.2. Informative References 11.2. Informative References
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of
Interpretation", RFC 6407, DOI 10.17487/RFC6407, October
2011, <http://www.rfc-editor.org/info/rfc6407>.
[RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the [RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the
Internet checksum", RFC1071, September 1988. Internet checksum", RFC1071, September 1988.
[RFC1624] Rijsinghani, A., Ed., "Computation of the Internet Checksum [RFC1624] Rijsinghani, A., Ed., "Computation of the Internet Checksum
via Incremental Update", RFC1624, May 1994. via Incremental Update", RFC1624, May 1994.
[RFC1936] Touch, J. and B. Parham, "Implementing the Internet [RFC1936] Touch, J. and B. Parham, "Implementing the Internet
Checksum in Hardware", RFC1936, April 1996. Checksum in Hardware", RFC1936, April 1996.
[RFC4459] MTU and Fragmentation Issues with In-the-Network Tunneling. [RFC4459] MTU and Fragmentation Issues with In-the-Network Tunneling.
skipping to change at page 26, line 36 skipping to change at page 29, line 4
- Version 3 (L2TPv3)", RFC3931, 1999 - Version 3 (L2TPv3)", RFC3931, 1999
[RFC5925] Touch, J., et al, "The TCP Authentication Option", RFC5925, [RFC5925] Touch, J., et al, "The TCP Authentication Option", RFC5925,
June 2010. June 2010.
[RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer
Security Version 1.2", RFC6347, 2012. Security Version 1.2", RFC6347, 2012.
[I.D.hy-nvo3-gue-4-nvo] Yong, L., Herbert, T., "Generic UDP [I.D.hy-nvo3-gue-4-nvo] Yong, L., Herbert, T., "Generic UDP
Encapsulation (GUE) for Network Virtualization Overlay" Encapsulation (GUE) for Network Virtualization Overlay"
draft-hy-nvo3-gue-4-nvo-03
[I.D.draft-mathis-frag-harmful] M. Mathis, J. Heffner, and B. [I.D.draft-mathis-frag-harmful] M. Mathis, J. Heffner, and B.
Chandler, "Fragmentation Considered Very Harmful" Chandler, "Fragmentation Considered Very Harmful"
[I.D.previdi-6man-sr-header] Previdi S. et al, "IPv6 Segment Routing
Header (SRH) draft-ietf-6man-segment-routing-header-02
[I.D.templin-aerolink] F. Templin, "Transmission of IP Packets over [I.D.templin-aerolink] F. Templin, "Transmission of IP Packets over
AERO Links" draft-templin-aerolink-62.txt AERO Links" draft-templin-aerolink-62
[I.D.
[UDPENCAP] T. Herbert, "UDP Encapsulation in Linux", [UDPENCAP] T. Herbert, "UDP Encapsulation in Linux",
http://people.netfilter.org/pablo/netdev0.1/papers/UDP- http://people.netfilter.org/pablo/netdev0.1/papers/UDP-
Encapsulation-in-Linux.pdf Encapsulation-in-Linux.pdf
Authors' Addresses Authors' Addresses
Tom Herbert Tom Herbert
Facebook Facebook
1 Hacker Way 1 Hacker Way
Menlo Park, CA Menlo Park, CA
 End of changes. 131 change blocks. 
467 lines changed or deleted 581 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/