draft-ietf-intarea-gue-extensions-05.txt   draft-ietf-intarea-gue-extensions-06.txt 
INTERNET-DRAFT T. Herbert INTERNET-DRAFT T. Herbert
Intended Status: Proposed Standard Quantonium Intended Status: Proposed Standard Quantonium
Expires: March 4, 2019 L. Yong Expires: September 9, 2019 L. Yong
Huawei Independent
F. Templin F. Templin
Boeing Boeing
August 31, 2018 March 8, 2019
Extensions for Generic UDP Encapsulation Extensions for Generic UDP Encapsulation
draft-ietf-intarea-gue-extensions-05 draft-ietf-intarea-gue-extensions-06
Abstract Abstract
This specification defines a set of the initial optional extensions This specification defines a set of the initial optional extensions
for Generic UDP Encapsulation (GUE). for Generic UDP Encapsulation (GUE).
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.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
4.1. Extension field format . . . . . . . . . . . . . . . . . . 7 4.1. Extension field format . . . . . . . . . . . . . . . . . . 7
4.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4.1. Extension field format . . . . . . . . . . . . . . . . 9 4.4.1. Extension field format . . . . . . . . . . . . . . . . 9
4.3.1. Operation . . . . . . . . . . . . . . . . . . . . . . . 8 4.3.1. Operation . . . . . . . . . . . . . . . . . . . . . . . 8
4.3.1.1. Transmitter operation . . . . . . . . . . . . . . . 8 4.3.1.1. Transmitter operation . . . . . . . . . . . . . . . 8
4.3.1.2. Receiver operation . . . . . . . . . . . . . . . . 9 4.3.1.2. Receiver operation . . . . . . . . . . . . . . . . 9
4.4. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4.1. Extension field format . . . . . . . . . . . . . . . . 9 4.4.1. Extension field format . . . . . . . . . . . . . . . . 9
4.4.2. Selecting a hash algorithm . . . . . . . . . . . . . . 10 4.4.2. Selecting a hash algorithm . . . . . . . . . . . . . . 10
4.4.3. Pre-shared key management . . . . . . . . . . . . . . . 10 4.4.3. Pre-shared key management . . . . . . . . . . . . . . . 11
4.4.4. Operation . . . . . . . . . . . . . . . . . . . . . . . 11 4.4.4. Operation . . . . . . . . . . . . . . . . . . . . . . . 11
4.4.4.1. Transmitter operation . . . . . . . . . . . . . . . 11 4.4.4.1. Transmitter operation . . . . . . . . . . . . . . . 11
4.4.4.2. Receiver operation . . . . . . . . . . . . . . . . 11 4.4.4.2. Receiver operation . . . . . . . . . . . . . . . . 11
4.5. Interaction with other optional extensions . . . . . . . . 12 4.5. Interaction with other optional extensions . . . . . . . . 12
5. Fragmentation option . . . . . . . . . . . . . . . . . . . . . 12 5. Fragmentation option . . . . . . . . . . . . . . . . . . . . . 12
5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. Extension field format . . . . . . . . . . . . . . . . . . 14 5.3. Extension field format . . . . . . . . . . . . . . . . . . 14
5.4. Fragmentation procedure . . . . . . . . . . . . . . . . . 15 5.4. Fragmentation procedure . . . . . . . . . . . . . . . . . 15
5.5. Reassembly procedure . . . . . . . . . . . . . . . . . . . 17 5.5. Reassembly procedure . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 3, line 34 skipping to change at page 3, line 34
10.3. Corrupted alternate checksum flag . . . . . . . . . . . . 32 10.3. Corrupted alternate checksum flag . . . . . . . . . . . . 32
10.4. Security Considerations . . . . . . . . . . . . . . . . . 33 10.4. Security Considerations . . . . . . . . . . . . . . . . . 33
11. Processing order of options . . . . . . . . . . . . . . . . . 33 11. Processing order of options . . . . . . . . . . . . . . . . . 33
11.1. Processing order when sending . . . . . . . . . . . . . . 33 11.1. Processing order when sending . . . . . . . . . . . . . . 33
11.2. Processing order when receiving . . . . . . . . . . . . . 34 11.2. Processing order when receiving . . . . . . . . . . . . . 34
12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 35 13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 35
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
14.1. Normative References . . . . . . . . . . . . . . . . . . . 37 14.1. Normative References . . . . . . . . . . . . . . . . . . . 37
14.2. Informative References . . . . . . . . . . . . . . . . . . 37 14.2. Informative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
Generic UDP Encapsulation (GUE) [I.D.ietf-gue] is a generic and Generic UDP Encapsulation (GUE) [I.D.ietf-gue] is a generic and
extensible encapsulation protocol. This specification defines an extensible encapsulation protocol. This specification defines an
initial set of optional extensions for variant 0 of GUE. These initial set of optional extensions for variant 0 of GUE. These
extensions are the group identifier, security, fragmentation, payload extensions are the Group Identifier, Security, Fragmentation, Payload
transform, remote checksum offload, checksum, NAT address checksum, Transform, Remote Checksum Offload, Checksum, NAT Address Checksum,
and alternate checksum. and Alternate Checksum.
2. GUE header format with optional extensions 2. GUE header format with optional extensions
The format of a variant 0 GUE header with optional extensions is: The format of a variant 0 GUE header with optional extensions 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 | | | Length | Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
| 0 |C| Hlen | Proto/ctype |G| SEC |F|T|R|K|N|A| Rsvd | | 0 |C| Hlen | Proto/ctype |G| SEC |F|T|R|K|N|A| Rsvd |\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Group identifier (optional) | | Group identifier (optional) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | | |
~ Security (optional) ~ ~ Security (optional) ~ |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | | |
+ Fragmentation (optional) + + Fragmentation (optional) + |
| | | | GUE
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Payload transform (optional) | | Payload transform (optional) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Remote checksum offload (optional) | | Remote checksum offload (optional) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Checksum (optional) | | Checksum (optional) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| NAT Address Checksum (optional) | | NAT Address Checksum (optional) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | | |
+ Alternate checksum (optional) + + Alternate checksum (optional) + |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | | |
~ Private data (optional) ~ ~ Private data (optional) ~ |
| | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
The contents of the UDP header are described in [I.D.ietf-gue]. The contents of the UDP header are described in [I.D.ietf-gue].
The GUE header consists of: The GUE header consists of:
o Variant: Set to 0 to indicate GUE encapsulation header. Note o Variant: Set to 0 to indicate GUE encapsulation header. Note
that variant 1 (direct IP encapsulation) does not allow options. that variant 1 (direct IP encapsulation) does not allow optional
extensions.
o C: C-bit. Indicates the GUE payload is a control message when o C: C-bit. Indicates the GUE payload is a control message when
set, a data message when not set. GUE optional extensions can be set, a data message when not set. GUE optional extensions can be
used with either control or data messages unless otherwise used with either control or data messages unless otherwise
specified in the extension definition. stated in the specification of the extension.
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 extension fields and private data but not the first optional extension fields and private data but not the first
four bytes of the header. Computed as (header_len - 4) / 4. The four bytes of the header. Computed as (header_len - 4) / 4. The
length of the encapsulated packet is determined from the UDP length of the encapsulated packet is determined from the UDP
length and the Hlen: encapsulated_packet_length = UDP_Length - length and the Hlen: encapsulated_packet_length = UDP_Length -
12 - 4 * Hlen. 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 the IP
number for the packet in the payload; if the C bit is set this protocol number for the packet in the payload; if the C bit is
is the type of control message in the payload. The next header set this is the type of control message in the payload. The next
begins at the offset provided by Hlen. When the payload header begins at the offset provided by Hlen. When the payload
transform option or fragmentation option is used this field transform option or fragmentation option is used this field
SHOULD be set to protocol number 59 for a data message, or zero SHOULD be set to protocol number 59 for a data message, or zero
for a control message, to indicate there is no parsable protocol for a control message, to indicate there is no parsable protocol
in the payload. in the payload.
o G: Indicates the the group identifier extension field is o G: Indicates the the group identifier extension field is
present. The group identifier option is described in section 3. present. The group identifier option is described in section 3.
o SEC: Indicates security extension field is present. The security o SEC: Indicates security extension field is present. The security
option is described in section 4. option is described in section 4.
skipping to change at page 8, line 5 skipping to change at page 8, line 6
o 101b, 110b, 111b - Reserved values o 101b, 110b, 111b - Reserved values
4.2. Usage 4.2. Usage
The GUE security option is used to provide integrity and The GUE security option is used to provide integrity and
authentication of the GUE header. Security parameters (interpretation authentication of the GUE header. Security parameters (interpretation
of security field, key management, etc.) are expected to be of security field, key management, etc.) are expected to be
negotiated out-of-band between two communicating hosts. Two security negotiated out-of-band between two communicating hosts. Two security
algorithms are defined below. algorithms are defined below.
If the GUE security option is present in packet, the receiver MUST If the GUE security option is present in a packet, the receiver MUST
validate the security before processing other fields or accepting the validate the security before processing other fields or accepting the
packet. If the security option is not present, but the encapsulator packet. If the security option is not present, but the encapsulator
and decapsulator have agreed that security is required, the receiver and decapsulator have agreed that security is required, the receiver
MUST drop the packet as failing security checks. Note that this MUST drop the packet as failing security checks. Note that this
provision covers the case where the security flags bits are corrupted provision covers the case where the security flags bits are corrupted
such that they are reset to zero which would be interpreted as no such that they are reset to zero which would be interpreted as no
security field being present. security field being present.
4.3. Cookies 4.3. Cookies
skipping to change at page 9, line 49 skipping to change at page 9, line 50
| Payload offset | Payload length | | Payload offset | Payload length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ HMAC (256 bits) ~ ~ HMAC (256 bits) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields are: Fields are:
o HMAC Key-id: opaque field to allow multiple hash algorithms or o HMAC Key-id: opaque field to allow multiple hash algorithms or
key selection key selection
o Payload offset: offset in payload that indicates the first octet o Payload offset: offset in payload that indicates the first octet
of payload data included in the HMAC. of payload data included in the HMAC.
o Payload length: length of payload data starting from the payload o Payload length: length of payload data starting from the payload
offset to be included in the HMAC calculation. Zero offset to be included in the HMAC calculation. Zero indicates no
indicates no payload data in used in the payload data in used in the calculation.
calculation.
o HMAC: Output of HMAC computation o HMAC: Output of HMAC computation
The HMAC field is the output of the HMAC computation (per [RFC2104]) The HMAC field is the output of the HMAC computation (per [RFC2104])
using a pre-shared key identified by HMAC Key-id and of the text using a pre-shared key identified by HMAC Key-id and of the text
which consists of the concatenation of: which consists of the concatenation of:
o The IP addresses o The IP addresses
o The GUE header including all optional extensions and any private o The GUE header including all optional extensions and any private
data. For the purposes of calculating the HMAC value, the HMAC data. For the purposes of calculating the HMAC value, the HMAC
value is set all zeroes. value is set all zeroes.
o Optionally some or all of GUE payload. The portion of payload o Optionally some or all of GUE payload. The portion of payload
covered is indicated by an offset into the payload and a length covered is indicated by an offset into the payload and a length
relative to the offset. relative to the offset.
The purpose of the HMAC option is to verify the validity, the The purpose of the HMAC option is to verify the validity, the
integrity and the authentication of the GUE header itself and integrity, and the authentication of the GUE header itself and
optionally some or all of the GUE payload. optionally some or all of the GUE payload.
The HMAC Key-id field allows for the simultaneous existence of The HMAC Key-id field allows for the simultaneous existence of
several hash algorithms (SHA-256, SHA3-256 ... or future ones) as 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 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 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 pre-shared key roll-over when two pre-shared keys are supported
for a while when GUE endpoints converge to a fresher pre-shared key. for a while when GUE endpoints converge to a fresher pre-shared key.
4.4.2. Selecting a hash algorithm 4.4.2. Selecting a hash algorithm
The HMAC field in the HMAC option is 256 bit wide. Therefore, the The HMAC field in the HMAC option is 256 bits wide. Therefore, the
HMAC MUST be based on a hash function whose output is at least 256 HMAC MUST be based on a hash function whose output is at least 256
bits. If the output of the hash function is 256 bits, then this bits. If the output of the hash function is 256 bits, then this
output is simply inserted in the HMAC field. If the output of the 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 hash function is larger than 256 bits, then the output value is
truncated to 256 bits by taking the least-significant 256 bits and truncated to 256 bits by taking the least-significant 256 bits and
inserting them in the HMAC field. inserting them in the HMAC field.
GUE implementations can support multiple hash functions but MUST GUE implementations can support multiple hash functions but MUST
implement SHA-2 [FIPS180-4] in its SHA-256 variant. implement SHA-2 [FIPS180-4] and its SHA-256 variant.
4.4.3. Pre-shared key management 4.4.3. Pre-shared key management
The field HMAC Key-id allows for: The field HMAC Key-id allows for:
o Key roll-over: when there is a need to change the key (the hash o Key roll-over: when there is a need to change the key (the hash
pre-shared secret), then multiple pre-shared keys can be used pre-shared secret), then multiple pre-shared keys can be used
simultaneously. A decapsulator can have a table of <HMAC Key- simultaneously. A decapsulator can have a table of <HMAC Key-
id, pre-shared secret> for the currently active and future keys. id, pre-shared secret> for the currently active and future keys.
o Different algorithms: by extending the previous table to <HMAC o Different algorithms: by extending the previous table to <HMAC
Key-id, hash function, pre-shared secret>, the decapsulator can Key-id, hash function, pre-shared secret>, the decapsulator can
also support simultaneously several hash algorithms also support simultaneously several hash algorithms
skipping to change at page 12, line 17 skipping to change at page 12, line 18
the packet. the packet.
2) Note value in the HMAC field and set the HMAC field to zero. 2) Note value in the HMAC field and set the HMAC field to zero.
3) Calculate the HMAC hash over the concatenation of the IP source 3) Calculate the HMAC hash over the concatenation of the IP source
and destination addresses. The particular hash and keys are and destination addresses. The particular hash and keys are
agreed between the encpasulator and decapsulator out of band, agreed between the encpasulator and decapsulator out of band,
and the key for input to the hash is the one indicated by the and the key for input to the hash is the one indicated by the
Key-Id amongst the set of shared keys. Key-Id amongst the set of shared keys.
4) Continue the the HMAC hash calculation from the start of the 4) Continue the HMAC hash calculation from the start of the GUE
GUE header through the its length as indicated in GUE Hlen. header through the its length as indicated in GUE Hlen.
5) Continue the calculation to cover the payload portion if 5) Continue the calculation to cover the payload portion if
payload coverage is enabled (payload length field is non-zero). payload coverage is enabled (payload length field is non-zero).
The calculation continues at the payload offset for payload The calculation continues at the payload offset for payload
length bytes. length bytes.
6) Compare the computed HMAC value with the original value of the 6) Compare the computed HMAC value with the original value of the
HMAC field. If they are equal then the packet is accepted, if HMAC field. If they are equal then the packet is accepted, if
they are not equal then verification failed and the packet MUST they are not equal then verification failed and the packet MUST
be dropped. be dropped.
skipping to change at page 14, line 9 skipping to change at page 14, line 11
encapsulate each segment (a non-IP fragmentation approach). encapsulate each segment (a non-IP fragmentation approach).
Performing IP fragmentation on an encapsulated packet has the same Performing IP fragmentation on an encapsulated packet has the same
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 of alternative #1 follows the suggestion The second possibility of alternative #1 follows the suggestion
expressed in [RFC2764] and the fragmentation feature described in the expressed in [RFC2764] and the fragmentation feature described in the
AERO protocol [I.D.templin-aerolink]; that is for the tunneling AERO protocol [I.D.templin-aerolink]; that is for the tunneling
protocol itself to incorporate a segmentation and reassembly protocol itself to incorporate a fragmentation and reassembly
capability. In this method, fragmentation is part of the capability. 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 differs from IP fragmentation in that the IP for reassembly. This differs from IP fragmentation in that the IP
headers of the original packet are not replicated for each fragment. headers of the original packet are not replicated for each 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.
skipping to change at page 16, line 4 skipping to change at page 15, line 51
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 extension o F bit - Set to indicate presence of the fragmentation extension
field. field.
5.4. Fragmentation procedure 5.4. Fragmentation procedure
If an encapsulator determines that a packet must be fragmented (e.g. If an encapsulator determines that a packet must be fragmented (e.g.
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
an Identification value. The Identification MUST be different than an Identification value. The Identification MUST be different than
that of any other fragmented packet sent within the past 60 seconds that of any other fragmented packet sent within the past 60 seconds
(Maximum Segment Lifetime) with the same tunnel identification-- that (Maximum Segment Lifetime) or configured time with the same tunnel
is the same outer source and destination addresses, same UDP ports, identification-- that is the same outer source and destination
same orig-proto, and same group identifier if present. addresses, same UDP ports, same orig-proto, and same group identifier
if present.
The initial, unfragmented, and unencapsulated packet is referred to The initial, unfragmented, and unencapsulated packet is referred to
as the "original packet". This will be a layer 2 packet, layer 3 as the "original packet". This will be a layer 2 packet, layer 3
packet, or the payload of a GUE control message: packet, or the payload of a GUE control message:
+-------------------------------//------------------------------+ +-------------------------------//------------------------------+
| Original packet | | Original packet |
| (e.g. an IPv4, IPv6, Ethernet packet) | | (e.g. an IPv4, IPv6, Ethernet packet) |
+------------------------------//-------------------------------+ +------------------------------//-------------------------------+
Fragmentation and encapsulation are performed on the original packet Fragmentation and encapsulation are performed on the original packet
in sequence. First the packet is divided up in to fragments, and then in sequence. First the packet is divided up in to fragments, and then
each fragment is encapsulated. Each fragment, except possibly the each fragment is encapsulated. Each fragment, except possibly the
last ("rightmost") one, is an integer multiple of 8 octets long. last ("rightmost") one, is an integer multiple of eight octets long.
Fragments MUST be non-overlapping. The number of fragments SHOULD be Fragments MUST be non-overlapping. The number of fragments SHOULD be
minimized, and all but the last fragment should be approximately minimized, and all but the last fragment should be approximately
equal in length. equal in length.
The fragments are transmitted in separate "fragment packets" as: The fragments are transmitted in separate "fragment packets" as:
+--------------+--------------+---------------+--//--+----------+ +--------------+--------------+---------------+--//--+----------+
| first | second | third | | last | | first | second | third | | last |
| fragment | fragment | fragment | .... | fragment | | fragment | fragment | fragment | .... | fragment |
+--------------+--------------+---------------+--//--+----------+ +--------------+--------------+---------------+--//--+----------+
skipping to change at page 19, line 4 skipping to change at page 18, line 51
fragmentation. To mitigate this problem, an implementation SHOULD fragmentation. To mitigate this problem, an implementation SHOULD
ensure that the first fragment contains the headers of the ensure that the first fragment contains the headers of the
encapsulated packet at least through the transport header. encapsulated packet at least through the transport header.
A GUE node MUST be able to accept a fragmented packet that, after A GUE node MUST be able to accept a fragmented packet that, after
reassembly and decapsulation, is as large as 1500 octets. This means reassembly and decapsulation, is as large as 1500 octets. This means
that the node must configure a reassembly buffer that is at least as that the node must configure a reassembly buffer that is at least as
large as 1500 octets plus the maximum-sized encapsulation headers large as 1500 octets plus the maximum-sized encapsulation headers
that may be inserted during encapsulation. Implementations may find that may be inserted during encapsulation. Implementations may find
it more convenient and efficient to configure a reassembly buffer it more convenient and efficient to configure a reassembly buffer
size of 2KB which is large enough to accommodate even the largest set size of 2KB which should be large enough to accommodate even the
of encapsulation headers and provides a natural memory page size largest set of encapsulation headers and provides a natural memory
boundary. page size boundary.
5.6. Security Considerations 5.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.
skipping to change at page 19, line 37 skipping to change at page 19, line 36
o Enforce a minimum size for the first fragment. o Enforce a minimum size for the first fragment.
6. Payload transform option 6. Payload transform option
The payload transform option indicates that the GUE payload has been The payload transform option indicates that the GUE payload has been
transformed. Transforming a payload is done by running a function transformed. Transforming a payload is done by running a function
over the data and possibly modifying it (encrypting it for instance). over the data and possibly modifying it (encrypting it for instance).
The payload transform option indicates the method used to transform The payload transform option indicates the method used to transform
the data so that a decapsulator is able to validate and reverse the the data so that a decapsulator is able to validate and reverse the
transformation to recover the original data. Payload transformations transformation to recover the original data. Payload transformations
could include encryption, authentication, CRC coverage, and include encryption, authentication, CRC coverage, and compression.
compression. This specification defines a transformation for DTLS. This specification defines a transformation for DTLS.
6.1. Extension field format 6.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:
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
skipping to change at page 20, line 22 skipping to change at page 20, line 22
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 purposes or proprietary mechanisms. experimental purposes or proprietary mechanisms.
P_C_type: Indicates the protocol or control type of the P_C_type: Indicates the protocol or control type of the
untransformed payload. When payload transform option is untransformed payload. When payload transform option is
present, proto/ctype in the GUE header is set to 59 ("No present, proto/ctype in the GUE header is set to 59 ("No
next header") for a data message and zero for a control next header") for a data message and zero for a control
message. The IP protocol or control message type of the message. The IP protocol or control message type of the
untransformed payload MUST be 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.
Info: A field that can be set according to the requirements of Info: A field that can be set according to the requirements of
each payload transform type. If the specification for a each payload transform type. If the specification for a
payload transform type does not specify how this field is to payload transform type does not specify how this field is to
be set, then the field MUST be set to zero. be set, then the field MUST be set to zero.
skipping to change at page 21, line 28 skipping to change at page 21, line 27
create the security option. A decapsulator does processing in create the security option. A decapsulator does processing in
reverse-- the security option is processed (GUE header is validated) reverse-- the security option is processed (GUE header is validated)
and then the reverse payload transform is performed. and then the reverse payload transform is performed.
In order to get flow entropy from the payload, an encapsulator should In order to get flow entropy from the payload, an encapsulator should
derive the flow entropy before performing a payload transform. derive the flow entropy before performing a payload transform.
6.4. DTLS transform 6.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 (DTLS) [RFC6347]. An encapsulator would apply DTLS to
payload so that the payload packets are encrypted and the GUE header the GUE payload so that the payload packets are encrypted and the GUE
remains in plaintext. The payload transform option is set to indicate header remains in plaintext. The payload transform option is set to
that the payload is interpreted as a DTLS record. indicate that the payload is interpreted as a DTLS record.
The payload transform option for DTLS is: The payload transform option for DTLS 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | P_C_type | 0 | | 1 | P_C_type | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DTLS [RFC6347] provides a packet fragmentation capability. To avoid DTLS [RFC6347] provides a packet fragmentation capability. To avoid
skipping to change at page 23, line 8 skipping to change at page 23, line 5
7.2. Usage 7.2. Usage
7.2.1. Transmitter operation 7.2.1. Transmitter operation
The typical actions to set remote checksum offload on transmit 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 remote checksum offload option. The start offset and the remote checksum offload option. The start offset and
checksum offset are 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 (i.e. UDP checksum).
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.
7.2.2. Receiver operation 7.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:
skipping to change at page 23, line 42 skipping to change at page 23, line 39
greater than the length of the packet, then the packet MUST be greater than the length of the packet, then the packet MUST be
dropped. If checksum offset is greater then the length of the dropped. If checksum offset is greater then the length of the
packet minus 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
is the deduced checksum to set in the checksum field of the is the deduced checksum to set in the checksum field of the
encapsulated transport packet. encapsulated transport packet.
In pseudo code: In pseudo code:
csum: initialized to checksum computed from start (outer IP csum: initialized to checksum computed from start (outer IP
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
skipping to change at page 28, line 40 skipping to change at page 28, line 40
The NAT address checksum (NAC) option contains the checksum computed The NAT address checksum (NAC) option contains the checksum computed
over the IP addresses of the packet. The computed value can be used over the IP addresses of the packet. The computed value can be used
by a receiver to adjust a transport layer checksum that was affected by a receiver to adjust a transport layer checksum that was affected
by NAT changing the IP addresses. This option is only useful when GUE by NAT changing the IP addresses. This option is only useful when GUE
encapsulates a transport layer packet that has a checksum with a encapsulates a transport layer packet that has a checksum with a
pseudo header that includes the IP addresses (such as TCP or UDP). pseudo header that includes the IP addresses (such as TCP or UDP).
9.1. Extension field format 9.1. Extension field format
The presence of the NAT checksum address option is indicated by the N The presence of the NAT address checksum option is indicated by the N
bit in the GUE header. bit in the GUE header.
The format of the NAT checksum address extension is: The format of the NAT checksum address extension 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 | Reserved | | Checksum | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of the option are: The fields of the option are:
o Checksum: Computed checksum value. This checksum covers the o Checksum: Computed checksum value. This checksum covers the
outer IP addresses. outer IP addresses.
o Reserved: Must be zero on transmit. o Reserved: Must be zero on transmit.
9.2. Usage 9.2. Usage
The NAT address extension SHOULD be set on transmit when The NAT address extension SHOULD be set on transmit when
skipping to change at page 30, line 39 skipping to change at page 30, line 39
2) Compute the checksum over the IP addresses in the received 2) Compute the checksum over the IP addresses in the received
packet packet
3) Subtract the resultant from the checksum value in the NAC 3) Subtract the resultant from the checksum value in the NAC
option. If the difference is non-zero then NAT has changed the option. If the difference is non-zero then NAT has changed the
addresses addresses
4) When processing a transport layer containing a checksum 4) When processing a transport layer containing a checksum
affected by NAT on the IP addresses, add the difference into affected by NAT on the IP addresses, add the difference into
the checksum calculation when verify the packet. the checksum calculation when verifying the packet.
In pseudo codes this is: In pseudo codes this is:
actual = checksum(IP addresses) actual = checksum(IP addresses)
diff = actual - NAC_value diff = actual - NAC_value
verify = checksum(transport packet) + checksum(pseudo header) verify = checksum(transport packet) + checksum(pseudo header)
+ diff + diff
if (verify == 0) if (verify == 0)
packet is good packet is good
skipping to change at page 32, line 19 skipping to change at page 32, line 19
payload coverage is enabled (payload coverage field is non- payload coverage is enabled (payload coverage field is non-
zero). If the length of the payload coverage is not aligned to zero). If the length of the payload coverage is not aligned to
four bytes, logically append zero bytes up to the necessary four bytes, logically append zero bytes up to the necessary
alignment for the purposes of CRC calculation. alignment for the purposes of CRC calculation.
4) Set the resultant value in the CRC field. 4) Set the resultant value in the CRC field.
10.2.2. Receiver operation 10.2.2. Receiver operation
If the GUE alternative checksum option is present, the receiver MUST If the GUE alternative checksum option is present, the receiver MUST
validate the checksum before processing any other fields or accepting validate the checksum before processing any other fields, except the
the packet. GUE checksum, or accepting the packet.
The procedure for verifying the alternate checksum is: The procedure for verifying the alternate checksum is:
1) If the payload coverage length is greater than the length of 1) If the payload coverage length is greater than the length of
the encapsulated payload then drop the packet. the encapsulated payload then drop the packet.
2) Note value in the CRC field and set the CRC field to zero. 2) Note value in the CRC field and set the CRC field to zero.
3) Calculate the CRC using the CRC-32C algorithm from the start of 3) Calculate the CRC using the CRC-32C algorithm from the start of
the GUE header through the its length as indicated in GUE Hlen. the GUE header through the its length as indicated in GUE Hlen.
skipping to change at page 34, line 48 skipping to change at page 34, line 48
ecapsulator and decapsulator. ecapsulator and decapsulator.
12. Security Considerations 12. Security Considerations
Encapsulation of a network protocol in GUE should not increase Encapsulation of a network protocol in GUE should not increase
security risk, nor provide additional security in itself. GUE security risk, nor provide additional security in itself. GUE
requires that the source port for UDP packets SHOULD be randomly requires that the source port for UDP packets SHOULD be randomly
seeded to mitigate some possible denial service attacks. 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 option and payload encryption through GUE is a concern, the GUE security option and payload
using the the transform option SHOULD be used to remove the concern. encryption using the the transform option SHOULD be used to remove
If the integrity is the only concern, the tunnel may consider use of the concern. If the integrity is the only concern, the tunnel may
GUE security only for optimization. Likewise, if privacy is the only consider use of GUE security only for optimization. Likewise, if
concern, the tunnel may use a GUE transform for encryption only. privacy is the only concern, the tunnel may use a GUE transform for
encryption only.
If GUE payload already provides secure mechanism, e.g., the payload If a GUE payload already provides secure mechanism, e.g., the payload
is IPsec packets, it is still valuable to consider use of GUE is an IPsec packet, it is still valuable to consider use of GUE
security. security.
GUE may rely on other secure tunnel mechanisms such as DTLS [RFC6347] 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 over the whole UDP payload for securing the whole GUE packet or IPsec
[RFC4301] to achieve the secure transport over an IP network or [RFC4301] to achieve the secure transport over an IP network or
Internet. Internet.
IPsec [RFC4301] was designed as a network security mechanism, and IPsec [RFC4301] was designed as a network security mechanism, and
therefore it resides at the network layer. As such, if the tunnel is therefore resides at the network layer. As such, if the tunnel is
secured with IPsec, the UDP header would not be visible to secured with IPsec, the UDP header would not be visible to
intermediate routers in either IPsec tunnel or transport mode. This intermediate routers in either IPsec tunnel or transport mode. This
is a drawback since it prohibits intermediate routers to perform load is a drawback since it prohibits intermediate routers to perform load
balancing based on the flow entropy in UDP header. In addition, this balancing based on the flow entropy in UDP header. In addition, this
method prohibits any middle box function on the path. method prohibits some middle box functions on the path.
By comparison, DTLS [RFC6347] was designed for application level By comparison, DTLS [RFC6347] was designed for application level
security and can better preserve network and transport layer protocol security and can better preserve network and transport layer protocol
information than IPsec [RFC4301]. Using DTLS over UDP to secure the information than IPsec [RFC4301]. Using DTLS over UDP to secure the
GUE tunnel, both GUE header and payload will be encrypted. In order GUE tunnel, both GUE header and payload will be encrypted. In order
to differentiate plaintext GUE header from encrypted GUE header, the to differentiate plaintext GUE header from the encrypted GUE header,
destination port of the UDP header between two must be different, the destination port of the UDP header between two must be different,
which essentially requires another standard UDP port for GUE with which essentially requires another standard UDP port for GUE with
DTLS. The drawback on this method is to prevent a middle box DTLS. The drawback on this method is to prevent a middle box
operation to GUE tunnel on the path. operation to GUE tunnel on the path.
Use of two independent tunnel mechanisms such as GUE and DTLS over 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 UDP to carry a network protocol over an IP network adds some overlap
and complexity. For example, fragmentation will be done twice. and complexity. For example, fragmentation will be done twice.
As the result, a GUE tunnel SHOULD use the security mechanisms As the result, a GUE tunnel SHOULD use the security mechanisms
specified in this document to provide secure transport over an IP specified in this document to provide secure transport over an IP
skipping to change at page 37, line 29 skipping to change at page 37, line 29
14.1. Normative References 14.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.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, DOI (IPv6) Specification", STD 86, RFC 8200, DOI
10.17487/RFC8200, July 2017, <https://www.rfc- 10.17487/RFC8200, July 2017, <https://www.rfc-
editor.org/info/rfc8200>. editor.org/info/rfc8200>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer
Communication Layers", STD 3, RFC 1122, October 1989. Security Version 1.2", RFC6347, 2012.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-
editor.org/info/rfc793>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI
10.17487/RFC5226, May 2008, <http://www.rfc- 10.17487/RFC5226, May 2008, <http://www.rfc-
editor.org/info/rfc5226>. editor.org/info/rfc5226>.
[I.D.ietf-gue] T. Herbert, L. Yong, and O. Zia, "Generic UDP [I.D.ietf-gue] T. Herbert, L. Yong, and O. Zia, "Generic UDP
Encapsulation" draft-ietf-intarea-gue-01 Encapsulation" draft-ietf-intarea-gue-01
[FIPS180-4] Secure Hash Standard (SHS), Nation Institute of Standards
and Technology, 8/2015
14.2. Informative References 14.2. Informative References
[RFC3931] Lau, J., Townsley, W., et al, "Layer Two Tunneling Protocol [RFC3931] Lau, J., Townsley, W., et al, "Layer Two Tunneling Protocol
- Version 3 (L2TPv3)", RFC3931, 1999 - Version 3 (L2TPv3)", RFC3931, 1999
[RFC2104] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2104] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol" , RFC 2401, DOI 10.17487/RFC2401, Internet Protocol" , RFC 2401, DOI 10.17487/RFC2401,
November 1998, <http://www.rfc-editor.org/info/rfc2401>. November 1998, <http://www.rfc-editor.org/info/rfc2401>.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of
Interpretation" , RFC 6407, DOI 10.17487/RFC6407, October Interpretation" , RFC 6407, DOI 10.17487/RFC6407, October
2011, <http://www.rfc-editor.org/info/rfc6407>. 2011, <http://www.rfc-editor.org/info/rfc6407>.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- [RFC4459] Savola, ., "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April
2006, <http://www.rfc-editor.org/info/rfc4459>. 2006, <http://www.rfc-editor.org/info/rfc4459>.
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963,
July 2007, <http://www.rfc-editor.org/info/rfc4963>. July 2007, <http://www.rfc-editor.org/info/rfc4963>.
[RFC2764] B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis, "A [RFC2764] B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis, "A
Framework for IP Based Virtual Private Networks", RFC2764, Framework for IP Based Virtual Private Networks", RFC2764,
February 2000. February 2000.
skipping to change at page 38, line 29 skipping to change at page 38, line 36
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858, Considerations for IP Fragment Filtering", RFC 1858,
October 1995. October 1995.
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny [RFC3128] Miller, I., "Protection Against a Variant of the Tiny
Fragment Attack (RFC 1858)", RFC 3128, June 2001. Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer
Security Version 1.2", RFC6347, 2012.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-
editor.org/info/rfc793>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC
6936, DOI 10.17487/RFC6936, April 2013, <http://www.rfc-
editor.org/info/rfc6936>.
[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.
[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 draft-hy-nvo3-gue-4-nvo-03
[I.D.previdi-6man-sr-header] Previdi S. et al, "IPv6 Segment Routing [I.D.previdi-6man-sr-header] Previdi S. et al, "IPv6 Segment Routing
Header (SRH) draft-ietf-6man-segment-routing-header-02 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 AERO Links" draft-templin-aerolink-62
[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
[FIPS180-4] Secure Hash Standard (SHS), Nation Institute of Standards
and Technology, 8/2015
Authors' Addresses Authors' Addresses
Tom Herbert Tom Herbert
Quantonium Quantonium
4701 Patrick Henry Dr. 4701 Patrick Henry Dr.
Santa Clara, CA Santa Clara, CA
USA USA
EMail: tom@herbertland.com EMail: tom@herbertland.com
Lucy Yong Lucy Yong
Huawei USA Austin, TX
5340 Legacy Dr.
Plano, TX 75024
USA USA
Email: lucy.yong@huawei.com Email: lucy.yong@huawei.com
Fred L. Templin Fred L. Templin
Boeing Research & Technology Boeing Research & Technology
P.O. Box 3707 P.O. Box 3707
Seattle, WA 98124 Seattle, WA 98124
USA USA
 End of changes. 47 change blocks. 
113 lines changed or deleted 103 lines changed or added

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