draft-ietf-intarea-gue-extensions-02.txt   draft-ietf-intarea-gue-extensions-03.txt 
INTERNET-DRAFT T. Herbert INTERNET-DRAFT T. Herbert
Intended Status: Proposed Standard Quantonium Intended Status: Proposed Standard Quantonium
Expires: July 6, 2018 L. Yong Expires: July 22, 2018 L. Yong
Huawei Huawei
F. Templin F. Templin
Boeing Boeing
January 2, 2018 January 18, 2018
Extensions for Generic UDP Encapsulation Extensions for Generic UDP Encapsulation
draft-ietf-intarea-gue-extensions-02 draft-ietf-intarea-gue-extensions-03
Abstract Abstract
This specification defines a set of the fundamental optional This specification defines a set of the fundamental optional
extensions for Generic UDP Encapsulation (GUE). extensions 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 2, line 34 skipping to change at page 2, line 34
4.4.1. Extension field format . . . . . . . . . . . . . . . . 8 4.4.1. Extension field format . . . . . . . . . . . . . . . . 8
4.4.2. Selecting a hash algorithm . . . . . . . . . . . . . . 9 4.4.2. Selecting a hash algorithm . . . . . . . . . . . . . . 9
4.4.3. Pre-shared key management . . . . . . . . . . . . . . . 10 4.4.3. Pre-shared key management . . . . . . . . . . . . . . . 10
4.5. Interaction with other optional extensions . . . . . . . . 10 4.5. Interaction with other optional extensions . . . . . . . . 10
5. Fragmentation option . . . . . . . . . . . . . . . . . . . . . 10 5. Fragmentation option . . . . . . . . . . . . . . . . . . . . . 10
5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Extension field format . . . . . . . . . . . . . . . . . . 12 5.3. Extension field format . . . . . . . . . . . . . . . . . . 12
5.4. Fragmentation procedure . . . . . . . . . . . . . . . . . 13 5.4. Fragmentation procedure . . . . . . . . . . . . . . . . . 13
5.5. Reassembly procedure . . . . . . . . . . . . . . . . . . . 15 5.5. Reassembly procedure . . . . . . . . . . . . . . . . . . . 15
5.6. Security Considerations . . . . . . . . . . . . . . . . . 17 5.6. Security Considerations . . . . . . . . . . . . . . . . . 16
6. Payload transform option . . . . . . . . . . . . . . . . . . . 17 6. Payload transform option . . . . . . . . . . . . . . . . . . . 17
6.1. Extension field format . . . . . . . . . . . . . . . . . . 18 6.1. Extension field format . . . . . . . . . . . . . . . . . . 17
6.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.3. Interaction with other optional extensions . . . . . . . . 19 6.3. Interaction with other optional extensions . . . . . . . . 18
6.4. DTLS transform . . . . . . . . . . . . . . . . . . . . . . 19 6.4. DTLS transform . . . . . . . . . . . . . . . . . . . . . . 19
7. Remote checksum offload option . . . . . . . . . . . . . . . . 20 7. Remote checksum offload option . . . . . . . . . . . . . . . . 19
7.1. Extension field format . . . . . . . . . . . . . . . . . . 20 7.1. Extension field format . . . . . . . . . . . . . . . . . . 20
7.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 21 7.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 20
7.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 21 7.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 21
7.3. Security Considerations . . . . . . . . . . . . . . . . . 22 7.3. Security Considerations . . . . . . . . . . . . . . . . . 22
8. Checksum option . . . . . . . . . . . . . . . . . . . . . . . 22 8. Checksum option . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Extension field format . . . . . . . . . . . . . . . . . . 23 8.1. Extension field format . . . . . . . . . . . . . . . . . . 22
8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 23 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 23
8.3. GUE checksum pseudo header . . . . . . . . . . . . . . . . 24 8.3. GUE checksum pseudo header . . . . . . . . . . . . . . . . 23
8.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.4.1. Transmitter operation . . . . . . . . . . . . . . . . . 25 8.4.1. Transmitter operation . . . . . . . . . . . . . . . . . 24
8.4.2.Receiver operation . . . . . . . . . . . . . . . . . . . 25 8.4.2. Receiver operation . . . . . . . . . . . . . . . . . . 25
8.6. Corrupted flags . . . . . . . . . . . . . . . . . . . . . . 26 8.5. Corrupted flags . . . . . . . . . . . . . . . . . . . . . 25
8.5. Security Considerations . . . . . . . . . . . . . . . . . 26 8.6. Security Considerations . . . . . . . . . . . . . . . . . 26
9. NAT checksum address option . . . . . . . . . . . . . . . . . 26 9. NAT checksum address option . . . . . . . . . . . . . . . . . 26
9.1. Extension field format . . . . . . . . . . . . . . . . . . 26 9.1. Extension field format . . . . . . . . . . . . . . . . . . 26
9.3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.3.1. Transmitter operation . . . . . . . . . . . . . . . . . 27 9.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 27
9.3.2. Receiver operation . . . . . . . . . . . . . . . . . . 28 9.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 28
10. Alternative checksum option . . . . . . . . . . . . . . . . . 28 10. Alternative checksum option . . . . . . . . . . . . . . . . . 28
10.1. Extension field format . . . . . . . . . . . . . . . . . 28 10.1. Extension field format . . . . . . . . . . . . . . . . . . 28
10.1.1. 16-bit CRC alternate checksum . . . . . . . . . . . . 29 10.1.1. CRC-16-CCITT and CRC-16 alternate checksums . . . . . 29
10.1.2. 32-bit CRC alternate checksum . . . . . . . . . . . . 30 10.1.2. 32-bit CRC alternate checksum . . . . . . . . . . . . 30
10.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.2.1. Transmitter operation . . . . . . . . . . . . . . . . 30 10.2.1. Transmitter operation . . . . . . . . . . . . . . . . 30
10.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 31 10.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 31
10.3. Corrupted flags . . . . . . . . . . . . . . . . . . . . . 31 10.3. Corrupted flags . . . . . . . . . . . . . . . . . . . . . 31
10.4. Security Considerations . . . . . . . . . . . . . . . . . 32 10.4. Security Considerations . . . . . . . . . . . . . . . . . 32
11. Processing order of options . . . . . . . . . . . . . . . . . 32 11. Processing order of options . . . . . . . . . . . . . . . . . 32
11.1. Processing order when sending . . . . . . . . . . . . . . 32 11.1. Processing order when sending . . . . . . . . . . . . . . 32
11.2. Processing order when receiving . . . . . . . . . . . . . 33 11.2. Processing order when receiving . . . . . . . . . . . . . 33
12. Security Considerations . . . . . . . . . . . . . . . . . . . 33 12. Security Considerations . . . . . . . . . . . . . . . . . . . 33
13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 34 13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 34
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
14.1. Normative References . . . . . . . . . . . . . . . . . . 35 14.1. Normative References . . . . . . . . . . . . . . . . . . . 36
14.2. Informative References . . . . . . . . . . . . . . . . . 36 14.2. Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
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 a extensible encapsulation protocol. This specification defines a
fundamental set of optional extensions for version 0 of GUE. These fundamental set of optional extensions for version 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.
skipping to change at page 5, line 21 skipping to change at page 5, line 21
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. specified in the extension 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 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 IP protocol
number for the packet in the payload; if the C bit is set this number for the packet in the payload; if the C bit is set this
is the type of control message in 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 payload begins at the offset provided by Hlen. When the payload
transform option or fragmentation option is used this field MAY transform option or fragmentation option is used this field
be set to protocol number 59 for a data message, or zero for a SHOULD be set to protocol number 59 for a data message, or zero
control message, to indicate no next header for the payload. for a control message, to indicate no next header for 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.
o F: Indicates fragmentation extension field is present. The o F: Indicates fragmentation extension field is present. The
fragmentation option is described in section 5. fragmentation option is described in section 5.
skipping to change at page 6, line 12 skipping to change at page 6, line 12
o N: Indicates NAT address checksum field is present. The NAT o N: Indicates NAT address checksum field is present. The NAT
address checksum option is described in section 9. address checksum option is described in section 9.
o ACS: Indicates alternative checksum field is present. The o ACS: Indicates alternative checksum field is present. The
alternative checksum option is described in section 10. alternative checksum option is described in section 10.
o Private data is described in [I.D.ietf-gue]. o Private data is described in [I.D.ietf-gue].
3. Group identifier option 3. Group identifier option
The group identifier classifies packet that logically belong to the A group identifier classifies packets that logically belong to the
same group. Groups are arbitrarily defined for different purposes and same group. Groups are arbitrarily defined for different purposes and
their definition is shared between the communicating end nodes. their definition is shared between the communicating end nodes.
3.1. Extension field format 3.1. Extension field format
The presence of the GUE group identifier option is indicated in the G The presence of the GUE group identifier option is indicated in the G
flag bit of the GUE header. flag bit of the GUE header.
The format of the group identifier option is: The format of the group identifier option is:
skipping to change at page 6, line 35 skipping to change at page 6, line 35
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group identifier | | Group identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of the option are: The fields of the option are:
o Group identifier: Identifier value of a group. o Group identifier: Identifier value of a group.
3.2. Usage 3.2. Usage
The group identifier is set by an encapsulator to indicate to the The group identifier is set by an encapsulator to indicate that a
decapsulator that a packet belongs to a group. Groups may be packet belongs to a group. Groups may be arbitrarily defined to
arbitrarily defined to classify packets. Specific use cases of the classify packets. Specific use cases of the group identifier may be
group identifier may be defined in other documents ([I.D.hy-nvo3-gue- defined in other documents ([I.D.hy-nvo3-gue-4-nvo] defines a use of
4-nvo] defines a use of this field to contain a virtual networking this field to contain a virtual networking identifier for
identifier for implementing network virtualization). implementing network virtualization).
Intermediate nodes MAY apply semantics to group identifiers if group Intermediate nodes MAY apply semantics to group identifiers if group
identifier information is shared and made global within a network. identifier information is shared and made global within a network.
For instance, a firewall could block packets based on a group For instance, a firewall could block packets based on a group
identifier that serves as a virtual identifier for a tenant. identifier that serves as a virtual identifier for a tenant.
4. Security option 4. Security option
The GUE security option provides origin authentication and integrity The GUE security option provides origin authentication and integrity
protection of the GUE header at tunnel end points to guarantee protection of the GUE header at tunnel end points to guarantee
skipping to change at page 7, line 27 skipping to change at page 7, line 27
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of the option are: The fields of the option are:
o Security (variable length). Contains the security information. o Security (variable length). Contains the security information.
The specific semantics and format of this field are expected to The specific semantics and format of this field are expected to
be negotiated between the two communicating nodes. be negotiated between the two communicating nodes.
To provide security capability, the SEC flags MUST be set. Different To provide security capability, the SEC flags MUST be set. Different
sizes are allowed to allow different methods and extensibility. The field sizes allow different methods and extensibility. The use of the
use of the security field is expected to be negotiated out of band security field is expected to be negotiated out of band between two
between two tunnel end points. tunnel end points.
The values in the SEC flags are: The values in the SEC flags are:
o 000b - No security field o 000b - No security field
o 001b - 64 bit security field o 001b - 64 bit security field
o 010b - 128 bit security field o 010b - 128 bit security field
o 011b - 256 bit security field o 011b - 256 bit security field
skipping to change at page 8, line 10 skipping to change at page 8, line 10
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.
4.3. Cookies 4.3. Cookies
The security field may be used as a cookie. This would be similar to The security field may be used as a cookie. This would be similar to
the cookie mechanism described in L2TP [RFC3931], and the general the cookie mechanism described in L2TP [RFC3931], and the general
properties should be the same. A cookie MAY be used to validate the properties should be the same. A cookie MAY be used to validate the
encapsulation. The cookie is a shared value between an encapsulator encapsulation. A cookie is a shared value between an encapsulator and
and decapsulator which SHOULD be chosen randomly and MAY be changed decapsulator which SHOULD be chosen randomly and MAY be changed
periodically. Different cookies MAY be used for logical flows between periodically. Different cookies MAY be used for logical flows between
the encapsulator and decapsulator, for instance packets sent with the encapsulator and decapsulator; for instance packets sent with
different VNIs in network virtualization [I.D.hy-nvo3-gue-4-nvo] different VNIs in network virtualization [I.D.hy-nvo3-gue-4-nvo]
might have different cookies. Cookies can be 64, 128, or 256 bits in might have different cookies. Cookies can be 64, 128, or 256 bits in
size. size.
4.4. HMAC 4.4. HMAC
Key-hashed message authentication code (HMAC) is a strong method of Key-hashed message authentication code (HMAC) is a strong method of
checking integrity and authentication of data. This sections defines checking integrity and authentication of data. This sections defines
a GUE security option for HMAC. Note that this is based on the HMAC 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- TLV description in "IPv6 Segment Routing Header (SRH)" [I.D.previdi-
skipping to change at page 12, line 5 skipping to change at page 12, line 5
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 segmentation and reassembly
capability that operates at the tunnel level. In this method, capability. In this method, fragmentation is part of the
fragmentation is part of the encapsulation and an encapsulation encapsulation and an encapsulation header contains the information
header contains the information for reassembly. This differs from IP for reassembly. This differs from IP fragmentation in that the IP
fragmentation in that the IP headers of the original packet are not headers of the original packet are not replicated for each fragment.
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.
o Encapsulation mechanisms for security and identification, such o Encapsulation mechanisms for security and identification, such
as group identifiers, can be applied to each segment. as group identifiers, can be applied to each segment.
skipping to change at page 13, line 42 skipping to change at page 13, line 42
(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 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 (eg. 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) with the same tunnel identification-- that
is the same outer source and destination addresses, same UDP ports, is the same outer source and destination addresses, same UDP ports,
same orig-proto, and same group identifier if present. same orig-proto, and same group identifier if present.
skipping to change at page 14, line 18 skipping to change at page 14, line 18
+-------------------------------//------------------------------+ +-------------------------------//------------------------------+
| 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 8 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 14, line 50 skipping to change at page 14, line 50
+------------------+----------------+-----------------------+ +------------------+----------------+-----------------------+
o o
o o
+------------------+----------------+-----------------------+ +------------------+----------------+-----------------------+
| IP/UDP header | GUE header | last | | IP/UDP header | GUE header | last |
| | 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. The
IP addresses and UDP ports MUST be the same for all fragments
o The IP addresses and UDP ports MUST be the same for all of a fragmented packet.
fragments of a fragmented packet.
(2) A GUE header that contains:
o The C-bit which is set to the same value for all the
fragments of a fragmented packet based on whether a control
message or data message was fragmented.
o A proto/ctype. In the first fragment this is set to the
value corresponding to the next header of the original
packet and will be either an IP protocol or a control type.
For subsequent fragments, this field is set to 0 for a
fragmented control message or 59 (no next header) for a
fragmented data message.
o The F bit is set and fragment extension field is present.
o Other GUE options. Note that options apply to the individual
GUE packet. For instance, the security option would be
validated before reassembly. The group identifier option
MUST be set to the same value for all fragments.
(3) The GUE fragmentation option. The contents of the extension
field include:
o Orig-proto specifies the protocol of the original packet.
o A Fragment Offset containing the offset of the fragment, in (2) A GUE header that indicates the fragmentation option is
8-octet units, relative to the start of the of the original present. The C-bit and and proto/ctype are set appropriately
packet. The Fragment Offset of the first ("leftmost") as described above.
fragment is 0.
o An M flag value of 0 if the fragment is the last (3) The GUE fragmentation option. Orig-protocol is set to the
("rightmost") one, else an M flag value of 1. protocol of the original packet. The M-bit is set for all
fragments except the last one. Fragment offset is set as the
offset of each fragment in the original packet.
o The Identification value generated for the original packet. (4) Other GUE extensions.
(4) The fragment itself. (5) The fragment itself as payload of the GUE packet.
5.5. Reassembly procedure 5.5. Reassembly procedure
At the destination, fragment packets are decapsulated and reassembled At the destination, fragment packets are decapsulated and reassembled
into their original, unfragmented form, as illustrated: into their original, unfragmented form, as illustrated:
+-------------------------------//------------------------------+ +-------------------------------//------------------------------+
| Original packet | | Original packet |
| (e.g. an IPv4, IPv6, Ethernet packet) | | (e.g. an IPv4, IPv6, Ethernet packet) |
+------------------------------//-------------------------------+ +------------------------------//-------------------------------+
skipping to change at page 17, line 5 skipping to change at page 16, line 27
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
does not contain the necessary headers for a stateful firewall. not contain the necessary headers for a stateful firewall. Sending
Sending small fragments like this has been used as an attack on small fragments like this has been used as an attack on IP
IP fragmentation. To mitigate this problem, an implementation fragmentation. To mitigate this problem, an implementation SHOULD
SHOULD ensure that the first fragment contains the headers of ensure that the first fragment contains the headers of the
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, A GUE node MUST be able to accept a fragmented packet that, after
after reassembly and decapsulation, is as large as 1500 octets. reassembly and decapsulation, is as large as 1500 octets. This means
This means that the node must configure a reassembly buffer that that the node must configure a reassembly buffer that is at least as
is at least as large as 1500 octets plus the maximum-sized large as 1500 octets plus the maximum-sized encapsulation headers
encapsulation headers that may be inserted during encapsulation. that may be inserted during encapsulation. Implementations may find
Implementations may find it more convenient and efficient to it more convenient and efficient to configure a reassembly buffer
configure a reassembly buffer size of 2KB which is large enough size of 2KB which is large enough to accommodate even the largest set
to accommodate even the largest set of encapsulation headers and of encapsulation headers and provides a natural memory page size
provides a natural memory page size boundary. 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.
o Application of GUE security (section 4) or IPsec [RFC4301]. o Application of GUE security (section 4) 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 accept data in overlapping segments.
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
skipping to change at page 18, line 12 skipping to change at page 17, line 34
could include encryption, authentication, CRC coverage, and could include encryption, authentication, CRC coverage, and
compression. This specification defines a transformation for DTLS. compression. 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 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | P_C_type | Data | | Type | P_C_type | Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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]
skipping to change at page 18, line 42 skipping to change at page 18, line 18
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.
Data: 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.
6.2. Usage 6.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 provides the interpret the payload of a GUE packet. The Type field provides the
method used to transform the payload, and the P_C_type field provides method used to transform the payload, and the P_C_type field provides
the protocol or control message type of the of payload before being the protocol or control message type of the of payload before being
skipping to change at page 19, line 44 skipping to change at page 19, line 20
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 [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 is interpreted as a DTLS record. that the payload is interpreted as a DTLS record.
The payload transform option for DLTS is: The payload transform option for DTLS 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | P_C_type | 0 | | 1 | P_C_type | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DTLS [RFC6347] provides packet fragmentation capability. To avoid DTLS [RFC6347] provides a packet fragmentation capability. To avoid
packet fragmentation performed multiple times, a GUE encapsulator packet fragmentation being performed multiple times, a GUE
SHOULD only perform the packet fragmentation at packet encapsulation encapsulator SHOULD use GUE fragmentation and not DTLS fragmentation.
process, i.e., not in the payload encryption process.
DTLS usage [RFC6347] is limited to a single DTLS session for any DTLS usage is limited to a single DTLS session for any specific
specific tunnel encapsulator/decapsulator pair (identified by source tunnel encapsulator/decapsulator pair (identified by source and
and destination IP addresses). Both IP addresses MUST be unicast 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 sessions 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 sessions with one or multiple decapsulators.
7. Remote checksum offload option 7. 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 in the In remote checksum offload the outer header checksum, that in the
skipping to change at page 21, line 38 skipping to change at page 21, line 16
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:
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 (i.e. validate non-zero UDP checksum).
2) Validate the remote checksum option. If checksum start is 2) Validate the remote checksum option. If checksum start is
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
skipping to change at page 22, line 47 skipping to change at page 22, line 25
7.3. Security Considerations 7.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 MUST apply security checks on the of this mechanism, a decapsulator MUST 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.
8. Checksum option 8. Checksum option
The GUE checksum option provides a checksum that covers the GUE The GUE checksum option provides a checksum that covers the GUE
header, a GUE pseudo header, and optionally part or all of the GUE header, a GUE pseudo header, and optionally all or part of the GUE
payload. The GUE pseudo header includes the corresponding IP payload. The GUE pseudo header includes the corresponding IP
addresses as well as the UDP ports of the encapsulating headers. This addresses as well as the UDP ports of the encapsulating headers. This
checksum should provide adequate protection against address checksum should provide protection against address corruption in IPv6
corruption in IPv6 when the UDP checksum is zero. Additionally, the when the UDP checksum is zero. Additionally, the GUE checksum
GUE checksum provides protection of the GUE header when the UDP provides protection of the GUE header when the UDP checksum is set to
checksum is set to zero with either IPv4 or IPv6. In particular, the zero with either IPv4 or IPv6. In particular, the GUE checksum can
GUE checksum can provide protection for some sensitive data, such as provide protection for some sensitive data, such as the virtual
the virtual network identifier ([I.D.hy-nvo3-gue-4-nvo]), which when network identifier ([I.D.hy-nvo3-gue-4-nvo]), which when corrupted
corrupted could lead to mis-delivery of a packet to the wrong virtual could lead to mis-delivery of a packet to the wrong virtual network.
network.
8.1. Extension field format 8.1. Extension field format
The presence of the GUE checksum option is indicated by the K bit in The presence of the GUE checksum option is indicated by the K bit in
the GUE header. the GUE header.
The format of the checksum extension is: The format of the checksum 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
skipping to change at page 24, line 15 skipping to change at page 23, line 38
8.3. GUE checksum pseudo header 8.3. GUE checksum pseudo header
The GUE pseudo header checksum is included in the GUE checksum to The GUE pseudo header checksum is included in the GUE checksum to
provide protection for the IP and UDP header elements which when provide protection for the IP and UDP header elements which when
corrupted could lead to misdelivery of the GUE packet. The GUE pseudo corrupted could lead to misdelivery of the GUE packet. The GUE pseudo
header checksum is similar to the standard IP pseudo header defined header checksum is similar to the standard IP pseudo header defined
in [RFC0768] and [RFC0793] for IPv4, and in [RFC8200] for IPv6. in [RFC0768] and [RFC0793] for IPv4, and in [RFC8200] for IPv6.
The GUE pseudo header for IPv4 is: The GUE pseudo header for IPv4 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address | | Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address | | Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source port | Destination port | | Source port | Destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The GUE pseudo header for IPv6 is: The GUE pseudo header for IPv6 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Source Address + + Source Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 24, line 47 skipping to change at page 24, line 30
+ Destination Address + + Destination Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source port | Destination port | | Source port | Destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The GUE pseudo header does not include payload length or protocol as The GUE pseudo header does not include payload length or protocol as
in the standard IP pseudo headers. The length field is deemed in the standard IP pseudo headers. The length field is deemed
unnecessary because a corrupted length field should not cause mis- unnecessary for inclusion because a corrupted length field should not
delivery, the GUE checksum is applied after GUE fragmentation, and cause mis-delivery, the GUE checksum is applied after GUE
without the length field the GUE pseudo header checksum is the same fragmentation, and without the length field the GUE pseudo header
for all packets of flow. checksum is the same for all packets of flow.
8.4. Usage 8.4. Usage
The GUE checksum is computed and verified following the standard The GUE checksum is computed and verified following the standard
process for computing the Internet checksum [RFC1071]. Checksum process for computing the Internet checksum [RFC1071]. Checksum
computation may be optimized per the mathematical properties computation may be optimized per the mathematical properties
including parallel computation and incremental updates. including parallel computation and incremental updates.
8.4.1. Transmitter operation 8.4.1. Transmitter operation
skipping to change at page 25, line 32 skipping to change at page 25, line 14
3) Calculate the checksum of the GUE pseudo header for IPv4 or 3) Calculate the checksum of the GUE pseudo header for IPv4 or
IPv6. IPv6.
4) Calculate checksum of payload portion if payload coverage is 4) Calculate checksum of payload portion if payload coverage is
enabled (payload coverage field is non-zero). If the length of enabled (payload coverage field is non-zero). If the length of
the payload coverage is odd, logically append a single zero the payload coverage is odd, logically append a single zero
byte for the purposes of checksum calculation. byte for the purposes of checksum calculation.
5) Add and fold the computed checksums for the GUE header, GUE 5) Add and fold the computed checksums for the GUE header, GUE
pseudo header and payload coverage. Set the bitwise not of the pseudo header, and payload coverage.
result in the GUE checksum field.
8.4.2.Receiver operation 6) Set the bitwise not of the resultant value in the GUE checksum
field.
8.4.2. Receiver operation
If the GUE checksum option is present, the receiver MUST validate the If the GUE checksum option is present, the receiver MUST validate the
checksum before processing any other fields or accepting the packet. checksum before processing any other fields or accepting the packet.
The procedure for verifying the checksum is: The procedure for verifying the 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) Calculate the checksum of the GUE header from the start of the 2) Calculate the checksum of the GUE header from the start of the
skipping to change at page 26, line 12 skipping to change at page 25, line 45
enabled (payload coverage is non-zero). If the length of the enabled (payload coverage is non-zero). If the length of the
payload coverage is odd logically append a single zero byte for payload coverage is odd logically append a single zero byte for
the purposes of checksum calculation. the purposes of checksum calculation.
5) Sum the computed checksums for the GUE header, GUE pseudo 5) Sum the computed checksums for the GUE header, GUE pseudo
header, and payload coverage. If the result is all 1 bits (-0 header, and payload coverage. If the result is all 1 bits (-0
in 1's complement arithmetic), the checksum is valid and the in 1's complement arithmetic), the checksum is valid and the
packet is accepted; otherwise the checksum is considered packet is accepted; otherwise the checksum is considered
invalid and the packet MUST be dropped. invalid and the packet MUST be dropped.
8.6. Corrupted flags 8.5. Corrupted flags
Note that the GUE checksum does not protect against the checksum flag Note that the GUE checksum does not protect against the checksum flag
(K flag) being corrupted. If an encapsulator sets the checksum flag (K flag) being corrupted. If an encapsulator sets the checksum flag
and option but the K bit flips to be zero, then a decapsulator will and option but the K bit flips to be zero, then a decapsulator will
incorrectly process the GUE packet as not having a checksum field. incorrectly process the GUE packet as not having a checksum field.
To mitigate this issue an encapsulator and depcapsulator might agree To mitigate this issue an encapsulator and depcapsulator might agree
that checksum is always required. This agreement could be established that checksum is always required. This agreement could be established
by configuration or GUE capability negotiation. by configuration or GUE capability negotiation.
8.5. Security Considerations 8.6. Security Considerations
The checksum option is only a mechanism for corruption detection, it The checksum option is only a mechanism for corruption detection, it
is not a security mechanism. To provide integrity checks or is not a security mechanism. To provide integrity checks or
authentication of the GUE header, the GUE security option SHOULD be authentication of the GUE header, the GUE security option SHOULD be
used. used.
9. NAT checksum address option 9. NAT checksum address option
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 affect by by a receiver to adjust a transport layer checksum that was affected
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 with a checksum with a pseudo encapsulates a transport layer packet that has a checksum with a
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 checksum address 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
skipping to change at page 27, line 4 skipping to change at page 26, line 35
The presence of the NAT checksum address option is indicated by the N The presence of the NAT checksum address 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.3. Usage 9.2. Usage
The NAT address address extension SHOULD be set on transmit when The NAT address extension SHOULD be set on transmit when
encapsulating a transport layer protocol whose checksum might be encapsulating a transport layer packet whose checksum might be
affected by NAT being performed on the outer IP header. If this affected by NAT being performed on the outer IP header. If this
option is used then the UDP checksum MUST be used (sent with non-zero option is used then the UDP checksum MUST be used (sent with non-zero
value). value).
The NAT address checksum is computed using the Internet checksum The NAT address checksum is computed using the Internet checksum
[RFC1071]. [RFC1071].
9.3.1. Transmitter operation 9.2.1. Transmitter operation
The procedure for setting the GUE checksum on transmit is:
An encapsulator computes the checksum value over the IP addresses in An encapsulator computes the checksum value over the IP addresses in
the IP header. the IP header.
1) Compute the ones complement checksum over the source and
destination IPv4 or IPv6 addresses.
2) Set the resultant value in the Checksum field.
For IPv4 the checksum is computed over: For IPv4 the checksum is computed over:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address | | Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address | | Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For IPv6 the checksum is computed over: For IPv6 the checksum is computed over:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Source Address + + Source Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Destination Address + + Destination Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9.3.2. Receiver operation 9.2.2. Receiver operation
1) Validate the UDP checksum is correct 1) Validate the UDP checksum is correct
2) Compute the checksum over the IP address in the received packet 2) Compute the checksum over the IP address in the received packet
3) Subtract the value in step #1 from the NAC value. If the 3) Subtract the resultant from the checksum value in the NAC
difference is non-zero then NAT has changed the addresses option. If the difference is non-zero then NAT has changed the
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 verify 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
10. Alternative checksum option 10. Alternative checksum option
The alternative checksum option contains a checksum over the GUE The alternative checksum option contains a check over the GUE header
header and optionally all or part of the GUE payload. The alternative and optionally all or part of the GUE payload. The alternative
checksum can provide stronger protection against data corruption than checksum can provide stronger protection against data corruption than
provided by the one's complement checksum used in the UDP checksum or provided by the one's complement checksum used in the UDP checksum or
the GUE checksum (section 8). the GUE checksum (section 8).
The alternative checksum flags are two bits which allow three methods The alternative checksum flags are two bits which allow three methods
to be defined. This specification proposes two: a 16-bit CRC method to be defined. This specification proposes three: two 16-bit CRC
and a 32-bit CRC method. variants and a 32-bit CRC method.
10.1. Extension field format 10.1. Extension field format
The format of the alternate checksum option is: The format of the alternate checksum 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Alternate checksum ~ ~ Alternate checksum ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 29, line 25 skipping to change at page 29, line 16
o Alternate checksum (variable length). Contains the checksum o Alternate checksum (variable length). Contains the checksum
information. information.
The presence of the alternate checksum option is indicated by the ACS The presence of the alternate checksum option is indicated by the ACS
bits in the GUE header. bits in the GUE header.
The values in the ACS flags are: The values in the ACS flags are:
o 00b - No alternate checksum field o 00b - No alternate checksum field
o 01b - 16-bit CRC o 01b - CRC-16-CCITT
o 10b - 32-bit CRC o 10b - CRC-16
0 11b - Reserved 0 11b - CRC-32
10.1.1. 16-bit CRC alternate checksum 10.1.1. CRC-16-CCITT and CRC-16 alternate checksums
The format of the 16-bit CRC alternative checksum field is: CRC-16-CCITT and CRC-16 have the same alternative checksum field
format. The format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC | Payload coverage | | CRC | Payload coverage |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of the option are: The fields of the option are:
o CRC: Computed CRC value. This CRC covers the GUE header o CRC: Computed CRC value. This CRC covers the GUE header
(including fields and private data covered by Hlen) and (including fields and private data covered by Hlen) and
optionally all or part of the payload (encapsulated packet). optionally all or part of the payload (encapsulated packet).
o Payload coverage: Number of bytes of payload to cover in the CRC o Payload coverage: Number of bytes of payload to cover in the CRC
calculation. Zero indicates that the checksum only covers the calculation. Zero indicates that the checksum only covers the
GUE header. If the value is greater than the encapsulated GUE header. If the value is greater than the encapsulated
payload length, the packet MUST be dropped. payload length, the packet MUST be dropped.
The 16-bit alternative checksum does not include a pseudo header The 16-bit alternative checksums do not include a pseudo header
containing IP addresses or ports. The CRC is calculated using CRC- containing IP addresses or ports.
CCITT algorithm (x^16 + x^12 + x^5 + 1 or polynomial 0x1021).
CRC-16-CCITT is calculated using the polynomial:
x^16 + x^12 + x^5 + 1 (polynomial representation 0x1021).
CRC-16 is calculated using the polynomial:
x^16 + x^15 + x^2 + 1 (polynomial representation 0x8005).
10.1.2. 32-bit CRC alternate checksum 10.1.2. 32-bit CRC alternate checksum
The format of the 32-bit CRC alternative checksum field is: The format of the 32-bit CRC alternative checksum 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Payload coverage | | Reserved | Payload coverage |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 30, line 30 skipping to change at page 30, line 32
o CRC: Computed CRC value. This CRC covers the GUE header o CRC: Computed CRC value. This CRC covers the GUE header
(including fields and private data covered by Hlen) and (including fields and private data covered by Hlen) and
optionally all or part of the payload (encapsulated packet). optionally all or part of the payload (encapsulated packet).
o Payload coverage: Number of bytes of payload to cover in the CRC o Payload coverage: Number of bytes of payload to cover in the CRC
calculation. Zero indicates that the checksum only covers the calculation. Zero indicates that the checksum only covers the
GUE header. If the value is greater than the encapsulated GUE header. If the value is greater than the encapsulated
payload length, the packet MUST be dropped. payload length, the packet MUST be dropped.
The 16-bit alternative checksum does not include a pseudo header The 32-bit alternative checksum does not include a pseudo header
containing IP addresses or ports. The CRC is calculated using CRC-32 containing IP addresses or ports.
algorithm (x^32 + x^26 + x^23 + x^22 + x^16 + x^12 +x ^10 + x^2 + x^7
+ x^5 + x^4 +x^2 + x + 1 or polynomial 0x04C11DB7). CRC-32 is calculated using the polynomial:
x^32 + x^26 + x^23 + x^22 + x^16 + x^12 +x ^10 + x^2 + x^7 + x^5 +
x^4 +x^2 + x + 1 (polynomial 0x04C11DB7).
10.2. Usage 10.2. Usage
The usage of the alternate checksum is the same for both the 16-bit The usage of the alternate checksum is the same for both the 16-bit
CRC and the 32-bit CRC methods except that the output CRC values have CRC and the 32-bit CRC methods except that the output CRC values have
different size. different sizes.
10.2.1. Transmitter operation 10.2.1. Transmitter operation
The procedure for setting the GUE alternative checksum on transmit The procedure for setting the GUE alternative checksum on transmit
is: is:
1) Create the GUE header including the alternative checksum field. 1) Create the GUE header including the alternative checksum field.
The CRC field is initialized to zero. The CRC field is initialized to zero.
2) Calculate the alternative checksum (either a 16-bit or 32-bit 2) Calculate the alternative checksum (either a 16-bit or 32-bit
skipping to change at page 31, line 40 skipping to change at page 31, line 44
4) Continue the calculation to cover the payload portion if 4) Continue the calculation to cover the payload portion if
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 per zero). If the length of the payload coverage is not aligned per
the algorithm (four bytes for CRC-32 and two bytes for CRC-16), the algorithm (four bytes for CRC-32 and two bytes for CRC-16),
logically append zero bytes up to the necessary alignment for logically append zero bytes up to the necessary alignment for
the purposes of CRC calculation. the purposes of CRC calculation.
5) Compare the computed value with the original value of the CRC 5) Compare the computed value with the original value of the CRC
field. If they are equal then that packet is accepted, if they field. If they are equal then that packet is accepted, if they
are not equal then verification filed and the packet MUST be are not equal then verification failed and the packet MUST be
dropped. dropped.
6) Restore the CRC field to its original value. 6) Restore the CRC field to its original value.
10.3. Corrupted flags 10.3. Corrupted flags
Similar to GUE checksum properties, the GUE alternate checksum does Similar to GUE checksum properties, the GUE alternate checksum does
not protect against the alternative checksum flags (ACS flags) being not protect against the alternative checksum flags (ACS flags) being
corrupted. If an encapsulator sets the alternative checksum flags and corrupted. If an encapsulator sets the alternative checksum flags and
option but the ACS bits flips to be zero, then a decapsulator will option but the ACS bits flips to be zero, then a decapsulator will
incorrectly process that packet as not having an alternate checksum incorrectly process that packet as not having an alternate checksum
field. field.
To mitigate this issue an encapsulator and depcapsulator might agree To mitigate this issue an encapsulator and depcapsulator might agree
that an alternate checksum is always required. This agreement could that an alternate checksum is always required. This agreement could
be established by configuration or GUE capability negotiation. be established by configuration or GUE capability negotiation.
10.4. Security Considerations 10.4. Security Considerations
The alternate checksum option is only a mechanism for corruption The alternate checksum option is only a mechanism for corruption
detection, it is not a security mechanism. To provide integrity detection, it is not a security mechanism. To provide integrity
checks or authentication of the GUE header, the GUE security option checks or authentication of the GUE header, the GUE security option
SHOULD be used. SHOULD be used.
11. Processing order of options 11. 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 transmission
receive. Note that some options, such as the checksum option, depend and reception. Note that some options, such as the checksum option,
on other fields in the GUE header to be set. depend on other fields in the GUE header to be initialized.
11.1. Processing order when sending 11.1. Processing order when sending
When setting the security option (HMAC option in particular), the When setting the security option (HMAC option in particular), the
checksum option, and the alternate checksum option-- all the GUE checksum option, and the alternate checksum option-- all the GUE
fields being used must be present and properly set in the header. The fields being used must be present and properly set in the header. The
checksum value in the checksum option or alternate checksum option checksum value in the checksum option or alternate checksum option
MUST be initialized to zero to ensure consistent HMAC and checksum MUST be initialized to zero to ensure consistent HMAC and checksum
calculation. calculation.
The order of processing options to send a GUE packet are: The order of processing options to send a GUE packet are:
1) Set group identifier option. 1) Fragment if necessary and set fragmentation option. If the
2) Fragment if necessary and set fragmentation option. If the
group identifier is present it is copied into each fragment. If group identifier is present it is copied into each fragment. If
payload transformation will increase the size of the payload payload transformation will increase the size of the payload
that MUST be accounted for when deciding how to fragment that MUST be accounted for when deciding how to fragment. Apply
processing below for each fragment
2) Set group identifier option (to the same value for each
fragment)
3) Perform payload transform (potentially on a fragment) and set 3) Perform payload transform (potentially on a fragment) and set
payload transform option. payload transform option.
4) Set Remote checksum offload. 4) Set Remote checksum offload.
5) Set NAT address checksum option. 5) Set NAT address checksum option.
6) Set security option per cookie or HMAC calculation. 6) Set security option per cookie or HMAC calculation.
7) Calculate GUE checksum and set checksum option. 7) Calculate GUE checksum and set checksum option.
8) Calculate GUE alternate checksum and set the alternate checksum 8) Calculate GUE alternate checksum and set the alternate checksum
option. option.
11.2. Processing order when receiving 11.2. Processing order when receiving
On reception the order of actions is reversed. On reception the order of actions is:
1) Verifiy GUE alternate checksum. 1) Verifiy GUE alternate checksum.
2) Verify GUE checksum. If the alternate checksum option is 2) Verify GUE checksum. If the alternate checksum option is
present, set the checksum fields to zero for computing the GUE present, set its checksum fields to zero for computing the GUE
checksum. After computation, restore the GUE checksum value. checksum. After computation, restore the checksum value in the
alternate checksum field.
3) Verify security option. If the GUE checksum option or alternate 3) Verify security option. If the GUE checksum option or alternate
checksum option is also present and HMAC computation is being checksum option are also present and HMAC computation is being
done over the GUE header, then set the checksum fields to zero done over the GUE header, then set the checksum fields to zero
for computing the HMAC. After computation, restore the checksum for computing the HMAC. After computation, restore the checksum
values. values.
4) Save the NAT address checksum value. It will be applied when 4) Save the NAT address checksum value. It will be applied when
processing the encapsulated packet. processing the encapsulated packet.
5) Adjust packet for remote checksum offload. 5) Adjust packet for remote checksum offload.
6) Perform payload transformation (i.e. decrypt payload). 6) Perform payload transformation (i.e. decrypt payload).
7) Perform reassembly. 7) Perform reassembly.
8) Process packet (take group identifier into account if present). 8) Process packet (take group identifier into account if present).
The relative processing order of GUE extensions and private fields is The relative processing order of GUE extensions and private fields is
unspecified in this specification. unspecified in this specification.
12. Security Considerations 12. Security Considerations
Encapsulation of network protocol in GUE should not increase security Encapsulation of a network protocol in GUE should not increase
risk, nor provide additional security in itself. GUE requires that security risk, nor provide additional security in itself. GUE
the source port for UDP packets SHOULD be randomly seeded to mitigate requires that the source port for UDP packets SHOULD be randomly
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, GUE security option and payload encryption
using the the transform option SHOULD be used to remove the concern. using the the transform option SHOULD be used to remove the concern.
If the integrity is the only concern, the tunnel may consider use of If the integrity is the only concern, the tunnel may consider use of
GUE security only for optimization. Likewise, if privacy is the only GUE security only for optimization. Likewise, if privacy is the only
concern, the tunnel may use GUE encryption function 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.
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
skipping to change at page 34, line 18 skipping to change at page 34, line 26
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 it 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 any middle box function on the path.
By comparison, DTLS [RFC6347] was designed with application security By comparison, DTLS [RFC6347] was designed for application level
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 encrypted GUE header, the
destination port of the UDP header between two must be different, 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
network or Internet when it is needed. GUE encapsulation can be used network or Internet when it is needed. GUE encapsulation can be used
as a secure transport mechanism over an IP network and Internet. as a secure transport mechanism over an IP network and Internet.
13. IANA Consideration 13. 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 Group specification. Specifically, an assignment is requested for the Group
Identfier, Security, Fragmentation, Payload Transform, Remote Identfier, Security, Fragmentation, Payload Transform, Remote
Checksum Offload, and Checksum extensions in the "GUE flag-fields" Checksum Offload, Checksum, NAT Checksum, and Alternate Checksum
registry. extensions in the "GUE flag-fields" registry.
+-------------+---------------+-------------+--------------------+ +-------------+---------------+-------------+--------------------+
| Flags bits | Field size | Description | Reference | | Flags bits | Field size | Description | Reference |
+-------------+---------------+-------------+--------------------+ +-------------+---------------+-------------+--------------------+
| Bit 0 | 4 bytes | Group | This document | | Bit 0 | 4 bytes | Group | This document |
| | | identifier | | | | | identifier | |
| | | | | | | | | |
| Bit 1..3 | 001->8 bytes | Security | This document | | Bit 1..3 | 001->8 bytes | Security | This document |
| | 010->16 bytes | | | | | 010->16 bytes | | |
| | 011->32 bytes | | | | | 011->32 bytes | | |
skipping to change at page 35, line 45 skipping to change at page 36, line 5
+----------------+------------------+---------------+ +----------------+------------------+---------------+
| 0 | Reserved | This document | | 0 | Reserved | This document |
| | | | | | | |
| 1 | DTLS | This document | | 1 | DTLS | This document |
| | | | | | | |
| 2..127 | Unassigned | | | 2..127 | Unassigned | |
| | | | | | | |
| 128..255 | User defined | This document | | 128..255 | User defined | This document |
+----------------+------------------+---------------+ +----------------+------------------+---------------+
14. References 14. References
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 - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
skipping to change at page 36, line 24 skipping to change at page 36, line 31
August 1980. August 1980.
[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
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
 End of changes. 94 change blocks. 
200 lines changed or deleted 211 lines changed or added

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