Internet DRAFT - draft-hy-gue-4-secure-transport
draft-hy-gue-4-secure-transport
Network Working Group L. Yong
Internet-Draft Huawei USA
Intended status: Standard Track T. Herbert
Facebook
Expires: September 2016 March 14, 2016
Generic UDP Encapsulation (GUE) for Secure Transport
draft-hy-gue-4-secure-transport-03
Abstract
This document specifies the ability of Generic UDP Encapsulation
(GUE) to provide secure transport over IP networks and the Internet,
including GUE header integrity protection and origin authentication
and GUE payload encryption. These are optional features of GUE.
Status of This Document
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Yong & Herbert [Page 1]
Internet-Draft GUE for Secure Transport March 2016
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction...................................................3
2. Terminology....................................................3
2.1. Requirements Language.....................................3
3. GUE Security...................................................3
4. GUE Payload Encryption.........................................5
5. Encapsulation/Decapsulation Operations.........................7
6. Considerations of Using Other Security Tunnel Mechanisms.......8
7. Security Considerations........................................9
7.1. GUE Security Field Usage..................................9
7.1.1. Cookies..............................................9
7.1.2. Secure hash..........................................9
8. IANA Considerations...........................................10
9. References....................................................10
9.1. Normative References.....................................10
9.2. Informative References...................................11
10. Authors' Addresses...........................................11
Yong & Herbert [Page 2]
Internet-Draft GUE for Secure Transport March 2016
1. Introduction
Generic UDP Encapsulation [GUE] is the protocol that specifies
tunneling a network protocol over an IP network or Internet and a
UDP tunnel. The tunneled network protocol is encapsulated in GUE
header [GUE] at a tunnel encapsulator, transported as a regular IP
packet, and decapsulated at the tunnel decapsulator.
This draft specifies the security capabilities for GUE. One security
capability is to provide origin authentication and integrity
protection of the GUE header at tunnel end points to guarantee
isolation between tunnels and mitigate Denial of Service attacks.
Another capability is payload encryption that prevents the payload
from eavesdropping, tampering, or message forgery. These security
capabilities are specified as optional features of GUE.
In theory, uses of GUE could leverage other existing tunnel
mechanisms that provides secure transport over Internet such as DTLS
[RFC6347] and IPsec[RFC4301]. Section 6 discusses the weakness to
rely on another tunnel mechanism for GUE secure transport.
2. Terminology
The terms defined in GUE [GUE] are used in this document.
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. GUE Security
This document proposes to allocate two flag bits from GUE optional
flag field as the Security flag for GUE integrity protection and
authentication validation. GUE header format with Security Flag is
shown in Figure 1. The second and third bits in GUE optional flag
field are allocated for Security mechanism.
Yong & Herbert [Page 3]
Internet-Draft GUE for Secure Transport March 2016
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 port | Destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|C| Hlen | Proto/Ctype |V|SEC| Undefined Flags |E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Network ID (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Field ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 GUE Header Format with Security Flag
o 'V' Virtualization flag: This flag is designated for network
virtualization overlay (NVO)[GUE4NVO].
o 'SEC' Security flags: Indicates presence of security field. To
provide security capability, the flags MUST be set. Different
sizes are allowed to allow different methods and extensibility.
The use of the security field is expected to be negotiated out of
band between two tunnel end points. Potential uses of the
security field are discussed in Section of Security
Considerations.
o 00 - No security field
o 01 - 64 bit security field
o 10 - 128 bit security field
o 11 - 256 bit security field
The usage of the key fields in the GUE header [GUE] for the security
mechanism is described as below:
o Ver: Set to 0x0. Security option is designed for GUE version 0.
o 'C' Control flag: When it set, control message presents and
control processing MUST occur after security validation.
o Hlen: length of optional fields (byte)/4. Note that Payload
Transform function does not require a private field.
Yong & Herbert [Page 4]
Internet-Draft GUE for Secure Transport March 2016
o Proto/ctype: Contain the protocol of the encapsulated payload
packet, i.e. next header when the C bit is not set. Contains a
control message type when the C bit is set. The next header
begins at the offset provided by Hlen.
'E' Extension flag. It is the last bit in the GUE header. For usage
of Extension field see [GUE]. The security transport does not
require use of any extension field.
UDP header field must be set per [GUE]. The checksum and length
implementation MUST be compliant with GUE implementation [GUE].
4. GUE Payload Encryption
The payload of a GUE packet can be secured using Datagram Transport
Layer Security [RFC6347]. An encapsulator would apply DTLS to the
GUE payload so that the payload packets are encrypted and the GUE
header remains in plaintext.
To differ encrypted payload from plaintext payload, the document
proposes allocating one flag from GUE optional flag field for
payload transformation indication and adding a 32 bit field when
Payload Transform flag is set. Following format shows GUE header
with Payload Transform flag, i.e. 'T' is set.
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 port | Destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|C| Hlen | Proto/Ctype |V|SEC|K|F|S|T| Flags |E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| VNID, security, GUE checksum, fragmentation, ~
~ Session (optional) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Transform Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 GUE Header with Payload Transform Flag
A 32 bits field in GUE header is for the payload transform function
and MUST be presented when Payload Transform flag T is set and MUST
Yong & Herbert [Page 5]
Internet-Draft GUE for Secure Transport March 2016
NOT be presented when clear. The format of Payload Transform Field
is in Figure 3.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Payload Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Payload Transform Field Format
Type: Payload Transform Type or Code point. Each payload transform
mechanism must have one code point registered in IANA. This
document specifies:
0x01: for DTLS [RFC6347]
0x80~0xFF: for private payload transform types
A private payload transform type can be used for experimental
purpose or vendor proprietary mechanism.
Payload Type: used to indicate the encrypted payload type. When
encryption flag is set, next protocol in the base header should set
to 59 ("No next header") for a data message and zero for a control
message. The payload type (IP protocol or control message type) of
the unencrypted paytload must be encoded in this field.
The benefit of this rule is to prevent a middle box from inspecting
the encrypted payload according to GUE next protocol. Assumption
here is that a middle box may understand GUE base header but does
not understand GUE option flag definitions.
Reserved field for DTLS type MUST set to Zero. For other
transformation type, the reserved field may be specified for a
purpose.
The usage of the key fields in the GUE header [GUE] for the payload
encryption mechanism is described as below:
o Ver: Set to 0x0. Payload transform option applies to version 0x0.
o Control flag: When it set, control message presents SHOULD be
encrypted except GUE base header.
o Hlen: length of optional fields (byte)/4
o Proto/CType: Set to 59. The payload type is encoded in the
payload encryption option field.
Yong & Herbert [Page 6]
Internet-Draft GUE for Secure Transport March 2016
o 'E' Extension flag. It is the last bit in the GUE header. For
usage of Extension field see [GUE]. The payload encryption does
not require use of any extension field.
UDP header usage for payload encryption mechanism: UDP dst port
SHOULD be filled with GUE port [GUE]; UDP src port MAY be filled
with entropy or a random value. The checksum and length
implementation MUST be compliant with GUE implementation [GUE].
5. Encapsulation/Decapsulation Operations
GUE secure transport mechanism applies to both IPv4 and IPv6
underlay networks. The outer IP address MUST be tunnel egress IP
address (dst) and tunnel ingress IP address (src). GUE security
option provides origin authentication and integrity to GUE based
tunnel; GUE payload encryption provides payload privacy over an IP
delivery network or Internet. Two functions are processed separately
at tunnel end points. A GUE tunnel can use both functions or use one
of them.
When both encryption and security are required, an encapsulator must
perform payload encryption first and then encapsulate the encrypted
packet with security flag and encryption flag set in GUE header; the
security field must be filled according Section 3 above; the
encryption field must be filled according to Section 4 above; the
decapsulator must decapsulate the packet first, then perform the
authentication validation; if the validation is successful, it
performs the payload decryption according the encryption information
in the payload encryption field in the header; if the validation
fails, the decapsulator must discard the packet and may generate an
alert to the management system. These processing rules also apply
when only one function, either encryption or security, is enabled,
except another function is not performed as stated above.
If GUE fragmentation is used in concert with the GUE security option
and/or payload transform option, the security and playload
transformation are performed after fragmentation at the encapsulator
and before reassembly at the decapsulator.
In order to get flow entropy from the payload, the encapsulator
needs to get the flow entropy first before performing the payload
encryption; then the flow entropy is inserted into UDP src port in
the GUE header.
DTLS [RFC6347] provides packet fragmentation capability. To avoid
packet fragmentation performed multiple times at GUE encapsulator,
GUE encapsulator SHOULD only perform the packet fragmentation at
Yong & Herbert [Page 7]
Internet-Draft GUE for Secure Transport March 2016
packet encapsulation process, i.e., not in payload encryption
process. The encryption process should apply to GUE control packets.
DTLS usage [RFC6347] is limited to a single DTLS session for any
specific tunnel encapsulator/decapsulator pair (identified by source
and destination IP addresses). Both IP addresses MUST be unicast
addresses - multicast traffic is not supported when DTLS is used. A
GUE tunnel decapsulator implementation that supports DTLS can
establish DTLS session(s) with one or multiple tunnel encapsulators,
and likewise a GUE tunnel encapsulator implementation can establish
DTLS session(s) with one or multiple decapsulators.
6. Considerations of Using Other Security Tunnel Mechanisms
GUE may rely on other secure tunnel mechanisms such as DTLS [RFC6347]
for securing the whole GUE packet or IPsec [RFC4301] to achieve the
secure transport over an IP network or Internet.
IPsec [RFC4301] was designed as a network security mechanism, and
therefore it resides at the network layer. As such, if the tunnel
is secured with IPsec, the UDP header would not be visible to
intermediate routers anymore in either IPsec tunnel or transport
mode. The big drawback here prohibits intermediate routers to
perform load balance based on the flow entropy in UDP header. In
addition, this method prohibits any middle box function on the path.
By comparison, DTLS [RFC6347] was designed with application security
and can better preserve network and transport layer protocol
information than IPsec [RFC4301]. Using DTLS to secure the GUE
tunnel, both GUE header and payload will be encrypted. In order to
differentiate plaintext GUE header from encrypted GUE header, the
destination port of the UDP header between two must be different,
which essentially requires another standard UDP port for GUE with
DTLS. The drawback on this method is to prevent a middle box
operation to GUE tunnel on the path.
Use of two independent tunnel mechanisms such as GUE and DTLS to
carry a network protocol over an IP network adds some overlap and
process complex. For example, fragmentation will be done twice.
As the result, a GUE tunnel SHOULD use the security mechanisms
specified in this document to provide secure transport over an IP
network or Internet when it is needed. GUE tunnel can be used as
secure transport mechanism over an IP network and Internet.
Yong & Herbert [Page 8]
Internet-Draft GUE for Secure Transport March 2016
7. Security Considerations
Encapsulation of network protocol in GUE should not increase
security risk, nor provide additional security in itself. GUE
requires that the source port for UDP packets should be randomly
seeded to mitigate some possible denial service attacks.
If the integrity and privacy of data packets being transported
through GUE is a concern, GUE security and payload encryption SHOULD
be used to remove the concern. If the integrity is the only concern,
the tunnel may consider use of GUE security only for optimization.
Likewise, if the privacy is the only concern, the tunnel may use GUE
encryption function only.
If GUE payload already provides secure mechanism, e.g., the payload
is IPsec packets, it is still valuable to consider use of GUE secure
mechanisms for the payload header privacy and the tunnel integrity.
7.1. GUE Security Field Usage
The GUE security field should be used to provide integrity and
authentication of the GUE header. Security negotiation
(interpretation of security field, key management, etc.) is expected
to be negotiated out of band between two communicating hosts. Two
possible uses for this field are outlined below, a more precise
specification is deferred to other documents.
7.1.1. Cookies
The security field may be used as a cookie. This would be similar to
cookie mechanism described in L2TP [RFC3931], and the general
properties should be the same. The cookie may be used to validate
the encapsulation. The cookie is a shared value between an
encapsulator and decapsulator which should be chosen randomly and
may be changed periodically. Different cookies may used for logical
flows between the encapsulator and decapsulator, for instance
packets sent with different VNIs in network virtualization [GUE4NVO]
might have different cookies.
7.1.2. Secure hash
Strong authentication of the GUE header can be provided using a
secure hash. This may follow the model of the TCP authentication
option [RFC5925]. In this case the security field holds a message
digest for the GUE header (e.g. 16 bytes from MD5). The digest might
be done over static fields in IP and UDP headers per negotiation
(addresses, ports, and protocols). In order to provide enough
Yong & Herbert [Page 9]
Internet-Draft GUE for Secure Transport March 2016
entropy, a random salt value in each packet might be added, for
instance the security field could be a 256 bit value which contains
128 bits of salt value, and a 128 bit digest value. The use of
secure hashes requires shared keys which are presumably negotiated
and rotated as needed out of band.
8. IANA Considerations
This document requires IANA to allocate:
Two bits in GUE option flag field for GUE Security.
One bit in GUE option flag field for GUE Payload Transform.
This document requires IANA to have a new registry for Encryption
Type and require two code points for:
0x01: for DTLS [RFC6347]
0x80~0xFF: for private payload transform
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC3931] Lau, J., Townsley, W., et al, "Layer Tow Tunneling
Protocol - Version 3 (L2TPv3)", RFC3931, 1999
[RFC4301] Kent, S., Seo, K., "Security Architecture for the Internet
Protocol", RFC4301, December 2005
[RFC5925] Touch, J., et al, "The TCP Authentication Option", RFC5925,
June 2010
[RFC6347] Rescoria, E., Modadugu, N., "Datagram Transport Layer
Security Version 1.2", RFC6347, 2012.
[GUE] Herbert, T., Yong, L., et al "Generic UNP Encapsulation",
draft-ietf-nvo3-gue-00, work in progress.
Yong & Herbert [Page 10]
Internet-Draft GUE for Secure Transport March 2016
9.2. Informative References
[GUE4NVO] Yong, L., and Herbert T., "Generic UNP Encapsulation for
NVO", draft-hy-nvo3-gue-4-nvo-01, work in progress.
10. Authors' Addresses
Lucy Yong
Huawei USA
Email: lucy.yong@huawei.com
Tom Herbert
Facebook
1 Hacker Way
Menlo Park, CA 94052
US
Email: tom@herbertland.com
Yong & Herbert [Page 11]
