draft-ietf-intarea-gue-extensions-04.txt   draft-ietf-intarea-gue-extensions-05.txt 
INTERNET-DRAFT T. Herbert INTERNET-DRAFT T. Herbert
Intended Status: Proposed Standard Quantonium Intended Status: Proposed Standard Quantonium
Expires: September 28, 2018 L. Yong Expires: March 4, 2019 L. Yong
Huawei Huawei
F. Templin F. Templin
Boeing Boeing
August 31, 2018
March 27, 2018
Extensions for Generic UDP Encapsulation Extensions for Generic UDP Encapsulation
draft-ietf-intarea-gue-extensions-04 draft-ietf-intarea-gue-extensions-05
Abstract Abstract
This specification defines a set of the fundamental optional This specification defines a set of the initial optional extensions
extensions for Generic UDP Encapsulation (GUE). for Generic UDP Encapsulation (GUE).
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 3, line 5 skipping to change at page 3, line 4
6. Payload transform option . . . . . . . . . . . . . . . . . . . 19 6. Payload transform option . . . . . . . . . . . . . . . . . . . 19
6.1. Extension field format . . . . . . . . . . . . . . . . . . 19 6.1. Extension field format . . . . . . . . . . . . . . . . . . 19
6.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3. Interaction with other optional extensions . . . . . . . . 21 6.3. Interaction with other optional extensions . . . . . . . . 21
6.4. DTLS transform . . . . . . . . . . . . . . . . . . . . . . 21 6.4. DTLS transform . . . . . . . . . . . . . . . . . . . . . . 21
7. Remote checksum offload option . . . . . . . . . . . . . . . . 22 7. Remote checksum offload option . . . . . . . . . . . . . . . . 22
7.1. Extension field format . . . . . . . . . . . . . . . . . . 22 7.1. Extension field format . . . . . . . . . . . . . . . . . . 22
7.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 22 7.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 22
7.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 23 7.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 23
7.3. Security Considerations . . . . . . . . . . . . . . . . . 24 7.3. Security Considerations . . . . . . . . . . . . . . . . . 24
8. Checksum option . . . . . . . . . . . . . . . . . . . . . . . 24 8. Checksum option . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. Extension field format . . . . . . . . . . . . . . . . . . 24 8.1. Extension field format . . . . . . . . . . . . . . . . . . 24
8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 25 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 25
8.3. GUE checksum pseudo header . . . . . . . . . . . . . . . . 25 8.3. GUE checksum pseudo header . . . . . . . . . . . . . . . . 25
8.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.4.1. Transmitter operation . . . . . . . . . . . . . . . . . 27 8.4.1. Transmitter operation . . . . . . . . . . . . . . . . . 27
8.4.2. Receiver operation . . . . . . . . . . . . . . . . . . 27 8.4.2. Receiver operation . . . . . . . . . . . . . . . . . . 27
8.5. Corrupted flags . . . . . . . . . . . . . . . . . . . . . 28 8.5. Corrupted checksum flag . . . . . . . . . . . . . . . . . 28
8.6. Security Considerations . . . . . . . . . . . . . . . . . 28 8.6. Security Considerations . . . . . . . . . . . . . . . . . 28
9. NAT checksum address option . . . . . . . . . . . . . . . . . 28 9. NAT checksum address option . . . . . . . . . . . . . . . . . 28
9.1. Extension field format . . . . . . . . . . . . . . . . . . 28 9.1. Extension field format . . . . . . . . . . . . . . . . . . 28
9.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 29 9.2.1. Transmitter operation . . . . . . . . . . . . . . . . . 29
9.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 30 9.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 30
10. Alternative checksum option . . . . . . . . . . . . . . . . . 30 10. Alternative checksum option . . . . . . . . . . . . . . . . . 30
10.1. Extension field format . . . . . . . . . . . . . . . . . . 31 10.1. Extension field format . . . . . . . . . . . . . . . . . . 31
10.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.2. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 32 10.2.2. Receiver operation . . . . . . . . . . . . . . . . . . 32
10.3. Corrupted flags . . . . . . . . . . . . . . . . . . . . . 32 10.3. Corrupted alternate checksum flag . . . . . . . . . . . . 32
10.4. Security Considerations . . . . . . . . . . . . . . . . . 33 10.4. Security Considerations . . . . . . . . . . . . . . . . . 33
11. Processing order of options . . . . . . . . . . . . . . . . . 33 11. Processing order of options . . . . . . . . . . . . . . . . . 33
11.1. Processing order when sending . . . . . . . . . . . . . . 33 11.1. Processing order when sending . . . . . . . . . . . . . . 33
11.2. Processing order when receiving . . . . . . . . . . . . . 34 11.2. Processing order when receiving . . . . . . . . . . . . . 34
12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 35 13. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 35
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
14.1. Normative References . . . . . . . . . . . . . . . . . . . 37 14.1. Normative References . . . . . . . . . . . . . . . . . . . 37
14.2. Informative References . . . . . . . . . . . . . . . . . . 37 14.2. Informative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 an
fundamental set of optional extensions for variant 0 of GUE. These initial set of optional extensions for variant 0 of GUE. These
extensions are the group identifier, security, fragmentation, payload extensions are the group identifier, security, fragmentation, payload
transform, remote checksum offload, checksum, NAT address checksum, transform, remote checksum offload, checksum, NAT address checksum,
and alternate checksum. and alternate checksum.
2. GUE header format with optional extensions 2. GUE header format with optional extensions
The format of a variant 0 GUE header with optional extensions is: The format of a variant 0 GUE header with optional extensions is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 5, line 29 skipping to change at page 5, line 29
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 transform option or fragmentation option is used this field
SHOULD be set to protocol number 59 for a data message, or zero SHOULD be set to protocol number 59 for a data message, or zero
for a control message, to indicate no next header for the for a control message, to indicate there is no parsable protocol
payload. in the payload.
o G: Indicates the the group identifier extension field is o G: Indicates the the group identifier extension field is
present. The group identifier option is described in section 3. present. The group identifier option is described in section 3.
o SEC: Indicates security extension field is present. The security o SEC: Indicates security extension field is present. The security
option is described in section 4. option is described in section 4.
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 18 skipping to change at page 6, line 18
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.
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 by 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:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group identifier | | Group identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 7 skipping to change at page 7, line 7
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
isolation between tunnels and mitigate Denial of Service attacks. isolation between tunnels and mitigate Denial of Service attacks.
4.1. Extension field format 4.1. Extension field format
The presence of the GUE security option is indicated in the SEC flag The presence of the GUE security option is indicated by the SEC flag
bits of the GUE header. bits of the GUE header.
The format of the security option is: The format of the security option is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Security ~ ~ Security ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
field sizes allow different methods and extensibility. The use of the field sizes allow different methods and extensibility. The use of the
security field is expected to be negotiated out of band between two security field is expected to be negotiated out-of-band 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
skipping to change at page 7, line 50 skipping to change at page 7, line 50
o 100b - 320 bit security field (HMAC) o 100b - 320 bit security field (HMAC)
o 101b, 110b, 111b - Reserved values o 101b, 110b, 111b - Reserved values
4.2. Usage 4.2. Usage
The GUE security option is used to provide integrity and The GUE security option is used to provide integrity and
authentication of the GUE header. Security parameters (interpretation authentication of the GUE header. Security parameters (interpretation
of security field, key management, etc.) are expected to be of security field, key management, etc.) are expected to be
negotiated out of band between two communicating hosts. Two security negotiated out-of-band between two communicating hosts. Two security
algorithms are defined below. algorithms are defined below.
If the GUE security option is present in packet, the receiver MUST If the GUE security option is present in packet, the receiver MUST
validate the security before processing other fields or accepting the validate the security before processing other fields or accepting the
packet. If the security option is not present but the encapsulator packet. If the security option is not present, but the encapsulator
and decapsulator have agreed that security is required, the receiver and decapsulator have agreed that security is required, the receiver
MUST drop the packet as failing security checks. Note that this MUST drop the packet as failing security checks. Note that this
provision covers the case where the security flags bits are corrupted provision covers the case where the security flags bits are corrupted
such that they are reset to zero which would be interpreted as no such that they are reset to zero which would be interpreted as no
security field being present. security field being present.
4.3. Cookies 4.3. Cookies
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
skipping to change at page 10, line 19 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. For the o The GUE header including all optional extensions and any private
purposes of calculating the HMAC value, the HMAC value is set data. For the purposes of calculating the HMAC value, the HMAC
all zeroes. value is set all zeroes.
o Optionally some or all of GUE payload. The portion of payload o Optionally some or all of GUE payload. The portion of payload
covered is indicated by an offset into the payload and a length covered is indicated by an offset into the payload and a length
relative to the offset. relative to the offset.
The purpose of the HMAC option is to verify the validity, the The purpose of the HMAC option is to verify the validity, the
integrity and the authentication of the GUE header itself and integrity and the authentication of the GUE header itself and
optionally some or all of the GUE payload. optionally some or all of the GUE payload.
The HMAC Key-id field allows for the simultaneous existence of The HMAC Key-id field allows for the simultaneous existence of
skipping to change at page 18, line 4 skipping to change at page 18, line 4
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
reassembled packet is the value of the GUE header proto/ctype reassembled packet is the value of the GUE header proto/ctype
skipping to change at page 20, line 40 skipping to change at page 20, line 40
Info: A field that can be set according to the requirements of Info: A field that can be set according to the requirements of
each payload transform type. If the specification for a each payload transform type. If the specification for a
payload transform type does not specify how this field is to payload transform type does not specify how this field is to
be set, then the field MUST be set to zero. be set, then the field MUST be set to zero.
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 payload before being
transformed. The payload transformation option is generic so that it transformed. The payload transformation option is generic so that it
can have both security related uses (such as DTLS) as well as non can have both security related uses (such as DTLS) as well as non
security related uses (such as compression, CRC, etc.). security related uses (such as compression, CRC, etc.).
An encapsulator performs payload transformation before transmission, An encapsulator performs payload transformation before transmission,
and a decapsulator performs the reverse transformation before and a decapsulator performs the reverse transformation before
accepting a packet. For example, if an encapsulator transforms a accepting a packet. For example, if an encapsulator transforms a
payload by encrypting it, the peer decaspsulator MUST decrypt the payload by encrypting it, the peer decaspsulator MUST decrypt the
payload before accepting the packet. If a decapsulator fails to payload before accepting the packet. If a decapsulator fails to
perform the reverse transformation or cannot validate the perform the reverse transformation or cannot validate the
skipping to change at page 27, line 14 skipping to change at page 27, line 14
including parallel computation and incremental updates. including parallel computation and incremental updates.
8.4.1. Transmitter operation 8.4.1. Transmitter operation
The procedure for setting the GUE checksum on transmit is: The procedure for setting the GUE checksum on transmit is:
1) Create the GUE header including the checksum and payload 1) Create the GUE header including the checksum and payload
coverage fields. The checksum field is initially set to zero. coverage fields. The checksum field is initially set to zero.
2) Calculate the 1's complement checksum of the GUE header from 2) Calculate the 1's complement checksum of the GUE header from
the start of the GUE header through the its length as indicated the start of the header through the its length as indicated in
in GUE Hlen. GUE Hlen.
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
skipping to change at page 27, line 44 skipping to change at page 27, line 44
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
header to the end as indicated by Hlen. header to the end as indicated by Hlen.
3) Calculate the checksum of the appropriate GUE pseudo header. 3) Calculate the checksum of the GUE pseudo header for IPv4 or
IPv6.
4) Calculate the checksum of payload if payload coverage is 4) Calculate the checksum of payload if payload coverage is
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.5. Corrupted flags 8.5. Corrupted checksum flag
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 capability negotiation.
8.6. 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
skipping to change at page 30, line 30 skipping to change at page 30, line 30
+ Destination Address + + Destination Address +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9.2.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 addresses in the received
packet
3) Subtract the resultant from the checksum value in the NAC 3) Subtract the resultant from the checksum value in the NAC
option. If the difference is non-zero then NAT has changed the option. If the difference is non-zero then NAT has changed the
addresses addresses
4) When processing a transport layer containing a checksum 4) When processing a transport layer containing a checksum
affected by NAT on the IP addresses, add the difference into affected by NAT on the IP addresses, add the difference into
the checksum calculation when verify the packet. the checksum calculation when verify the packet.
In pseudo codes this is: In pseudo codes this is:
skipping to change at page 31, line 8 skipping to change at page 31, line 8
+ 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 algorithm used is and optionally all or part of the GUE payload. The algorithm used is
CRC-32C which is the same as that used by iSCSI and SCTP. The CRC-32C which is the same as that used by iSCSI and SCTP. The
alternative checksum can provide stronger protection against data alternative checksum can provide stronger protection against data
corruption than provided by the one's complement checksum used in the corruption than that provided by the one's complement checksum used
UDP checksum or the GUE checksum (section 8). in the UDP checksum or the GUE checksum (section 8).
10.1. Extension field format 10.1. Extension field format
The presence of the GUE alternate checksum option is indicated by the The presence of the GUE alternate checksum option is indicated by the
A bit in the GUE header. A bit in the GUE header.
The format of alternate 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
skipping to change at page 31, line 45 skipping to change at page 31, line 45
payload length, the packet MUST be dropped. payload length, the packet MUST be dropped.
10.2. Usage 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-32C is calculated using the 0x1EDC6F41 polynomial: CRC-32C is calculated using the 0x1EDC6F41 polynomial:
x^32 + x^28 + x^27 + x^26 + x^25 + x^23 + x^22 + x^20 + x^19 + 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 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 CRC using the CRC-32C algorithm from the start of 2) Calculate the CRC using the CRC-32C algorithm from the start of
the GUE header through the its length as indicated in GUE Hlen. the GUE header through the its length as indicated in GUE Hlen.
skipping to change at page 32, line 45 skipping to change at page 32, line 45
four bytes, logically append zero bytes up to the necessary four bytes, logically append zero bytes up to the necessary
alignment for the purposes of CRC calculation. alignment for the purposes of CRC calculation.
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 alternate checksum flag
Similar to GUE checksum properties, the GUE alternate checksum does Similar to the GUE checksum, the GUE alternate checksum does not
not protect against the alternative checksum flag (A flag) being 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 A bit 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
skipping to change at page 33, line 25 skipping to change at page 33, line 25
11. Processing order of options 11. Processing order of options
Options MUST be processed in a specific order for both transmission Options MUST be processed in a specific order for both transmission
and reception. Note that some options, such as the checksum option, and reception. Note that some options, such as the checksum option,
depend on other fields in the GUE header to be initialized. 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, or 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) Fragment if necessary and set fragmentation option. If the 1) 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
skipping to change at page 34, line 35 skipping to change at page 34, line 35
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 between GUE extensions and private
unspecified in this specification. fields is unspecified in this specification. Any processing order
requirements regarding private data must be agreed upon between an
ecapsulator and decapsulator.
12. Security Considerations 12. Security Considerations
Encapsulation of a network protocol in GUE should not increase Encapsulation of a network protocol in GUE should not increase
security risk, nor provide additional security in itself. GUE security risk, nor provide additional security in itself. GUE
requires that the source port for UDP packets SHOULD be randomly requires that the source port for UDP packets SHOULD be randomly
seeded to mitigate some possible denial service attacks. seeded to mitigate some possible denial service attacks.
If the integrity and privacy of data packets being transported If the integrity and privacy of data packets being transported
through GUE is a concern, GUE security option and payload encryption through GUE is a concern, GUE security option and payload encryption
skipping to change at page 35, line 41 skipping to change at page 35, line 43
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 create a "GUE flag-fields" registry to allocate
flags and extension fields used with GUE. This shall be a registry of
bit assignments for flags, length of extension fields for
corresponding flags, and descriptive strings. There are sixteen bits
for primary GUE header flags (bit number 0-15). New values are
assigned in accordance with RFC Required policy [RFC5226]. New flags
should be allocated from high to low order bit contiguously without
holes. This document requests an initial assignment of flags in the
registry.
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, Checksum, NAT Checksum, and Alternate Checksum Checksum Offload, Checksum, NAT Checksum, and Alternate Checksum
extensions in the "GUE flag-fields" 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 |
 End of changes. 29 change blocks. 
37 lines changed or deleted 51 lines changed or added

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