draft-ietf-intarea-gue-extensions-03.txt   draft-ietf-intarea-gue-extensions-04.txt 
INTERNET-DRAFT T. Herbert INTERNET-DRAFT T. Herbert
Intended Status: Proposed Standard Quantonium Intended Status: Proposed Standard Quantonium
Expires: July 22, 2018 L. Yong Expires: September 28, 2018 L. Yong
Huawei Huawei
F. Templin F. Templin
Boeing Boeing
January 18, 2018 March 27, 2018
Extensions for Generic UDP Encapsulation Extensions for Generic UDP Encapsulation
draft-ietf-intarea-gue-extensions-03 draft-ietf-intarea-gue-extensions-04
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 23 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. GUE header format with optional extensions . . . . . . . . . . 4 2. GUE header format with optional extensions . . . . . . . . . . 4
3. Group identifier option . . . . . . . . . . . . . . . . . . . 6 3. Group identifier option . . . . . . . . . . . . . . . . . . . 6
3.1. Extension field format . . . . . . . . . . . . . . . . . . 6 3.1. Extension field format . . . . . . . . . . . . . . . . . . 6
3.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security option . . . . . . . . . . . . . . . . . . . . . . . 6 4. Security option . . . . . . . . . . . . . . . . . . . . . . . 6
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. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4.1. Extension field format . . . . . . . . . . . . . . . . 9
4.4.1. Extension field format . . . . . . . . . . . . . . . . 8 4.3.1. Operation . . . . . . . . . . . . . . . . . . . . . . . 8
4.4.2. Selecting a hash algorithm . . . . . . . . . . . . . . 9 4.3.1.1. Transmitter operation . . . . . . . . . . . . . . . 8
4.3.1.2. Receiver operation . . . . . . . . . . . . . . . . 9
4.4. HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.4.1. Extension field format . . . . . . . . . . . . . . . . 9
4.4.2. Selecting a hash algorithm . . . . . . . . . . . . . . 10
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.4.4. Operation . . . . . . . . . . . . . . . . . . . . . . . 11
5. Fragmentation option . . . . . . . . . . . . . . . . . . . . . 10 4.4.4.1. Transmitter operation . . . . . . . . . . . . . . . 11
5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4.4.2. Receiver operation . . . . . . . . . . . . . . . . 11
5.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.5. Interaction with other optional extensions . . . . . . . . 12
5.3. Extension field format . . . . . . . . . . . . . . . . . . 12 5. Fragmentation option . . . . . . . . . . . . . . . . . . . . . 12
5.4. Fragmentation procedure . . . . . . . . . . . . . . . . . 13 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 13
5.5. Reassembly procedure . . . . . . . . . . . . . . . . . . . 15 5.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.6. Security Considerations . . . . . . . . . . . . . . . . . 16 5.3. Extension field format . . . . . . . . . . . . . . . . . . 14
6. Payload transform option . . . . . . . . . . . . . . . . . . . 17 5.4. Fragmentation procedure . . . . . . . . . . . . . . . . . 15
6.1. Extension field format . . . . . . . . . . . . . . . . . . 17 5.5. Reassembly procedure . . . . . . . . . . . . . . . . . . . 17
6.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.6. Security Considerations . . . . . . . . . . . . . . . . . 19
6.3. Interaction with other optional extensions . . . . . . . . 18 6. Payload transform option . . . . . . . . . . . . . . . . . . . 19
6.4. DTLS transform . . . . . . . . . . . . . . . . . . . . . . 19 6.1. Extension field format . . . . . . . . . . . . . . . . . . 19
7. Remote checksum offload option . . . . . . . . . . . . . . . . 19 6.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Extension field format . . . . . . . . . . . . . . . . . . 20 6.3. Interaction with other optional extensions . . . . . . . . 21
7.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.4. DTLS transform . . . . . . . . . . . . . . . . . . . . . . 21
7.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 20 7. Remote checksum offload option . . . . . . . . . . . . . . . . 22
7.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 21 7.1. Extension field format . . . . . . . . . . . . . . . . . . 22
7.3. Security Considerations . . . . . . . . . . . . . . . . . 22 7.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. Checksum option . . . . . . . . . . . . . . . . . . . . . . . 22 7.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 22
8.1. Extension field format . . . . . . . . . . . . . . . . . . 22 7.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 23
8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 23 7.3. Security Considerations . . . . . . . . . . . . . . . . . 24
8.3. GUE checksum pseudo header . . . . . . . . . . . . . . . . 23 8. Checksum option . . . . . . . . . . . . . . . . . . . . . . . 24
8.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Extension field format . . . . . . . . . . . . . . . . . . 24
8.4.1. Transmitter operation . . . . . . . . . . . . . . . . . 24 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 25
8.4.2. Receiver operation . . . . . . . . . . . . . . . . . . 25 8.3. GUE checksum pseudo header . . . . . . . . . . . . . . . . 25
8.5. Corrupted flags . . . . . . . . . . . . . . . . . . . . . 25 8.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.6. Security Considerations . . . . . . . . . . . . . . . . . 26 8.4.1. Transmitter operation . . . . . . . . . . . . . . . . . 27
9. NAT checksum address option . . . . . . . . . . . . . . . . . 26 8.4.2. Receiver operation . . . . . . . . . . . . . . . . . . 27
9.1. Extension field format . . . . . . . . . . . . . . . . . . 26 8.5. Corrupted flags . . . . . . . . . . . . . . . . . . . . . 28
9.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.6. Security Considerations . . . . . . . . . . . . . . . . . 28
9.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 27 9. NAT checksum address option . . . . . . . . . . . . . . . . . 28
9.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 28 9.1. Extension field format . . . . . . . . . . . . . . . . . . 28
10. Alternative checksum option . . . . . . . . . . . . . . . . . 28 9.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Extension field format . . . . . . . . . . . . . . . . . . 28 9.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 29
10.1.1. CRC-16-CCITT and CRC-16 alternate checksums . . . . . 29 9.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 30
10.1.2. 32-bit CRC alternate checksum . . . . . . . . . . . . 30 10. Alternative checksum option . . . . . . . . . . . . . . . . . 30
10.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.1. Extension field format . . . . . . . . . . . . . . . . . . 31
10.2.1. Transmitter operation . . . . . . . . . . . . . . . . 30 10.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 31 10.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 32
10.3. Corrupted flags . . . . . . . . . . . . . . . . . . . . . 31 10.3. Corrupted flags . . . . . . . . . . . . . . . . . . . . . 32
10.4. Security Considerations . . . . . . . . . . . . . . . . . 32 10.4. Security Considerations . . . . . . . . . . . . . . . . . 33
11. Processing order of options . . . . . . . . . . . . . . . . . 32 11. Processing order of options . . . . . . . . . . . . . . . . . 33
11.1. Processing order when sending . . . . . . . . . . . . . . 32 11.1. Processing order when sending . . . . . . . . . . . . . . 33
11.2. Processing order when receiving . . . . . . . . . . . . . 33 11.2. Processing order when receiving . . . . . . . . . . . . . 34
12. Security Considerations . . . . . . . . . . . . . . . . . . . 33 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 34 13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 35
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
14.1. Normative References . . . . . . . . . . . . . . . . . . . 36 14.1. Normative References . . . . . . . . . . . . . . . . . . . 37
14.2. Informative References . . . . . . . . . . . . . . . . . . 36 14.2. Informative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
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 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 version 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 | UDP | Source port | Destination port | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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|ACS| Rsvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group identifier (optional) | | Group identifier (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Security (optional) ~ ~ Security (optional) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Fragmentation (optional) + + Fragmentation (optional) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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:
skipping to change at page 6, line 5 skipping to change at page 6, line 5
o R: Indicates the remote checksum extension field is present. The o R: Indicates the remote checksum extension field is present. The
remote checksum offload option is described in section 7. remote checksum offload option is described in section 7.
o K: Indicates checksum extension field is present. The checksum o K: Indicates checksum extension field is present. The checksum
option is described in section 8. option is described in section 8.
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 A: 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
A group identifier classifies packets 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.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
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
validate the security before processing other fields or accepting the
packet. If the security option is not present but the encapsulator
and decapsulator have agreed that security is required, the receiver
MUST drop the packet as failing security checks. Note that this
provision covers the case where the security flags bits are corrupted
such that they are reset to zero which would be interpreted as no
security field being present.
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. A cookie is a shared value between an encapsulator and encapsulation. A cookie is a shared value between an encapsulator 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.1. Extension field format
The cookie security option is a 64, 128, or 256 bit field. The
security flags are set to 001b, 010b, 011b respectively for the
corresponding field size.
The format of the field is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Cookie ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields are:
o Cookie: Shared cookie value between encapsulator and
decapsulator
4.3.1. Operation
4.3.1.1. Transmitter operation
The procedure for setting the GUE security cookie option on transmit
is:
1) Create the GUE header including the security field with the
selected length for the cookie. Set the cookie to the value
that is shared with decapsulator.
4.3.1.2. Receiver operation
The procedure for verifying the security cookie is:
1) Compare the received cookie to the expected shared cookie. If
both the lengths are equal and the cookie values are equal then
that packet is accepted, if the lengths or values are not equal
then verification failed and the packet MUST be dropped.
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-
6man-sr-header]. 6man-sr-header].
4.4.1. Extension field format 4.4.1. Extension field format
skipping to change at page 9, line 18 skipping to change at page 10, line 19
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 except for the o The GUE header including all optional extensions. For the
security option purposes of calculating the HMAC value, the HMAC 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.
A portion of the GUE payload MAY be included in the HMAC calculation.
The payload coverage is indicated in the option in the payload offset
and payload length fields. If no payload data is included in the HMAC
then the payload length field is set to zero. On reception, if the
sum of the payload offset and the payload length is greater than the
total length of the payload, then the packet MUST be dropped.
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 bit 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.
skipping to change at page 10, line 27 skipping to change at page 11, line 21
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
The pre-shared secret distribution can be done: The pre-shared secret distribution can be done:
o In the configuration of the endpoints o In the configuration of the endpoints
o Dynamically using a trusted key distribution such as [RFC6407] o Dynamically using a trusted key distribution such as [RFC6407]
4.4.4. Operation
4.4.4.1. Transmitter operation
The procedure for setting the GUE HMAC option on transmit is:
1) Create the GUE header including the 320 bit security field to
hold the HMAC option. Set the HMAC Key-Id, payload length, and
payload offset appropriately. The 16 byte HMAC field is
initialized to zero.
2) Calculate the HMAC hash over the concatenation of the IP source
and destination addresses. The particular hash and keys are
agreed between the encpasulator and decapsulator out of band,
and the key for input to the hash is the one indicated by the
Key-Id amongst the set of shared keys.
3) Continue the the HMAC hash calculation from the start of the
GUE header through the its length as indicated in GUE Hlen.
4) Continue the calculation to cover the payload portion if
payload coverage is enabled (payload coverage field is non-
zero). The calculation continues at the payload offset for
payload length bytes.
5) Set the resultant hash value in the HMAC field.
4.4.4.2. Receiver operation
The procedure for verifying the HMAC security option is:
1) If the payload offset plus the payload coverage length is
greater than the length of the encapsulated payload then drop
the packet.
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
and destination addresses. The particular hash and keys are
agreed between the encpasulator and decapsulator out of band,
and the key for input to the hash is the one indicated by the
Key-Id amongst the set of shared keys.
4) Continue the the HMAC hash calculation from the start of the
GUE header through the its length as indicated in GUE Hlen.
5) Continue the calculation to cover the payload portion if
payload coverage is enabled (payload length field is non-zero).
The calculation continues at the payload offset for payload
length bytes.
6) Compare the computed HMAC value with the original value of the
HMAC field. If they are equal then the packet is accepted, if
they are not equal then verification failed and the packet MUST
be dropped.
7) Restore the HMAC field to its original value.
4.5. Interaction with other optional extensions 4.5. Interaction with other optional extensions
If GUE fragmentation (section 5) is used in concert with the GUE If GUE fragmentation (section 5) is used in concert with the GUE
security option, the security option processing is performed after security option, the security option processing is performed after
fragmentation at the encapsulator and before reassembly at the fragmentation at the encapsulator and before reassembly at the
decapsulator. decapsulator.
The GUE payload transform option (section 6) may be used in concert The GUE payload transform option (section 6) may be used in concert
with the GUE security option. The payload transform option could be with the GUE security option. The payload transform option could be
used to encrypt the GUE payload to provide privacy for an used to encrypt the GUE payload to provide privacy for an
encapsulated packet during transit. The security option provides encapsulated packet during transit. The security option provides
authentication and integrity for the GUE header (including the authentication and integrity for the GUE header (including the
payload transform field in the header). The two functions are payload transform field in the header). The two functions are
processed separately at tunnel end points. A GUE tunnel can use both processed separately at tunnel end points. A GUE tunnel can use both
functions or use one of them. Section 6.3 details handling for when functions or use one of them. Section 6.3 details handling when both
both are used in a packet. are used in a packet.
5. Fragmentation option 5. Fragmentation option
The fragmentation option allows an encapsulator to perform The fragmentation option allows an encapsulator to perform
fragmentation of packets being ingress to a tunnel. Procedures for fragmentation of packets being ingress to a tunnel. Procedures for
fragmentation and reassembly are defined in this section. This fragmentation and reassembly are defined in this section. This
specification adapts the procedures for IP fragmentation and specification adapts the procedures for IP fragmentation and
reassembly described in [RFC0791] and [RFC8200]. Fragmentation can be reassembly described in [RFC0791] and [RFC8200]. Fragmentation can be
performed on both data and control messages in GUE. performed on both data and control messages in GUE.
skipping to change at page 15, line 40 skipping to change at page 17, line 51
The IP/UDP/GUE headers of each packet are retained until all The IP/UDP/GUE headers of each packet are retained until all
fragments have arrived. The reassembled packet is then composed fragments have arrived. The reassembled packet is then composed
of the decapsulated payloads in the GUE packets, and the of the decapsulated payloads in the GUE packets, and the
IP/UDP/GUE headers are discarded. IP/UDP/GUE headers are discarded.
When a GUE packet is received with the fragment extension, the When a GUE packet is received with the fragment extension, the
proto/ctype field in the GUE header MUST be validated. In the proto/ctype field in the GUE header MUST be validated. In the
case that the packet is a first fragment (fragment offset is case that the packet is a first fragment (fragment offset is
zero), the proto/ctype in the GUE header MUST equal the orig- zero), the proto/ctype in the GUE header MUST equal the orig-
proto value in the fragmentation option. For subsequent proto value in the fragmentation option. For subsequent
fragments (fragment offset is non-zero) the proto/ctype in the fragments, (fragment offset is non-zero) the proto/ctype in the
GUE header must be 0 for a control message or 59 (no-next-hdr) GUE header must be 0 for a control message or 59 (no-next-hdr)
for a data message. If the proto/ctype value is invalid for a for a data message. If the proto/ctype value is invalid for a
received packet it MUST be dropped. received packet it MUST be dropped.
An original packet is reassembled only from GUE fragment packets An original packet is reassembled only from GUE fragment packets
that have the same outer source address, destination address, that have the same outer source address, destination address,
UDP source port, UDP destination port, GUE header C-bit, group UDP source port, UDP destination port, GUE header C-bit, group
identifier if present, orig-proto value in the fragmentation identifier if present, orig-proto value in the fragmentation
option, and Fragment Identification. The protocol type or option, and Fragment Identification. The protocol type or
control message type (depending on the C-bit) for the control message type (depending on the C-bit) for the
skipping to change at page 28, line 30 skipping to change at page 31, line 4
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 check over the GUE header The alternative checksum option contains a check over the GUE header
and optionally all or part of the GUE payload. The alternative and optionally all or part of the GUE payload. The algorithm used is
checksum can provide stronger protection against data corruption than CRC-32C which is the same as that used by iSCSI and SCTP. The
provided by the one's complement checksum used in the UDP checksum or alternative checksum can provide stronger protection against data
the GUE checksum (section 8). corruption than provided by the one's complement checksum used in the
UDP checksum or the GUE checksum (section 8).
The alternative checksum flags are two bits which allow three methods
to be defined. This specification proposes three: two 16-bit CRC
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 presence of the GUE alternate checksum option is indicated by the
A bit in the GUE header.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Alternate checksum ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of the option are:
o Alternate checksum (variable length). Contains the checksum
information.
The presence of the alternate checksum option is indicated by the ACS
bits in the GUE header.
The values in the ACS flags are:
o 00b - No alternate checksum field
o 01b - CRC-16-CCITT
o 10b - CRC-16
0 11b - CRC-32
10.1.1. CRC-16-CCITT and CRC-16 alternate checksums
CRC-16-CCITT and CRC-16 have the same alternative checksum field
format. The format 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC | Payload coverage |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields of the option are:
o CRC: Computed CRC value. This CRC covers the GUE header
(including fields and private data covered by Hlen) and
optionally all or part of the payload (encapsulated packet).
o Payload coverage: Number of bytes of payload to cover in the CRC
calculation. Zero indicates that the checksum only covers the
GUE header. If the value is greater than the encapsulated
payload length, the packet MUST be dropped.
The 16-bit alternative checksums do not include a pseudo header
containing IP addresses or ports.
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
The format of the 32-bit CRC alternative checksum field is: The format of alternate 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC | | CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
10.2. Usage
The 32-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. containing IP addresses or ports.
CRC-32 is calculated using the polynomial: CRC-32C is calculated using the 0x1EDC6F41 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
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
different sizes.
10.2.1. Transmitter operation x^32 + x^28 + x^27 + x^26 + x^25 + x^23 + x^22 + x^20 + x^19 +
x^18 + x^14 +x^13 + +x^11 + x^10 +x^9 +x ^8 +x^ + 1
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 CRC using the CRC-32C algorithm from the start of
CRC) from the start of the GUE header through the its length as the GUE header through the its length as indicated in GUE Hlen.
indicated in GUE Hlen.
3) Continue the calculation to cover the payload portion if 3) 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 to
the algorithm (four bytes for CRC-32 and two bytes for CRC-16), four bytes, logically append zero bytes up to the necessary
logically append zero bytes up to the necessary alignment for alignment for the purposes of CRC calculation.
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 or accepting
the packet. 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 alternative checksum (either a 16-bit or 32-bit 3) Calculate the CRC using the CRC-32C algorithm from the start of
CRC) from the start of the GUE header through the its length as the GUE header through the its length as indicated in GUE Hlen.
indicated in GUE Hlen.
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 to
the algorithm (four bytes for CRC-32 and two bytes for CRC-16), four bytes, logically append zero bytes up to the necessary
logically append zero bytes up to the necessary alignment for 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 failed 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 flag (A flag) 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 A bit 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
skipping to change at page 33, line 7 skipping to change at page 33, line 51
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 alternate checksum and set the alternate checksum
8) Calculate GUE alternate checksum and set the alternate checksum
option. option.
8) Calculate GUE checksum and set checksum option.
11.2. Processing order when receiving 11.2. Processing order when receiving
On reception the order of actions is: On reception the order of actions is:
1) Verifiy GUE alternate checksum. 1) Verify GUE checksum.
2) Verify GUE checksum. If the alternate checksum option is 2) Verify alternate checksum. If the GUE checksum option is
present, set its checksum fields to zero for computing the GUE present, set its checksum fields to zero for computing the
checksum. After computation, restore the checksum value in the alternate checksum. After computation, restore the checksum
alternate checksum field. value in the GUE 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 are 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.
skipping to change at page 34, line 4 skipping to change at page 34, line 48
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, 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 a GUE transform for encryption 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
[RFC4301] to achieve the secure transport over an IP network or [RFC4301] to achieve the secure transport over an IP network or
Internet. Internet.
skipping to change at page 35, line 32 skipping to change at page 36, line 26
| Bit 6 | 4 bytes | Remote | This document | | Bit 6 | 4 bytes | Remote | This document |
| | | checksum | | | | | checksum | |
| | | offload | | | | | offload | |
| | | | | | | | | |
| Bit 7 | 4 bytes | Checksum | This document | | Bit 7 | 4 bytes | Checksum | This document |
| | | | | | | | | |
| Bit 8 | 4 bytes | NAT | This document | | Bit 8 | 4 bytes | NAT | This document |
| | | checksum | | | | | checksum | |
| | | address | | | | | address | |
| | | | | | | | | |
| Bit 9..10 | 01->4 bytes | Alternate | This document | | Bit 9 | 4 bytes | Alternate | This document |
| | 10->8 bytes | checksum | | | | | checksum | |
| | | | | | | | | |
| Bit 11..15 | | Unassigned | | | Bit 10..15 | | Unassigned | |
+-------------+---------------+-------------+--------------------+ +-------------+---------------+-------------+--------------------+
IANA is requested to set up a registry for the GUE payload transform IANA is requested to set up a registry for the GUE payload transform
types. Payload transform types are 8 bit values. New values for types. Payload transform types are 8 bit values. New values for
control types 1-127 are assigned via Standards Action [RFC5226]. control types 1-127 are assigned via Standards Action [RFC5226].
+----------------+------------------+---------------+ +----------------+------------------+---------------+
| Transform type | Description | Reference | | Transform type | Description | Reference |
+----------------+------------------+---------------+ +----------------+------------------+---------------+
| 0 | Reserved | This document | | 0 | Reserved | This document |
 End of changes. 39 change blocks. 
188 lines changed or deleted 220 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/