[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03
Network Working Group L. Yong
Internet-Draft Huawei USA
Intended status: Standard Track T. Herbert
Google
Expires: September 2015 March 6, 2015
Generic UDP Encapsulation (GUE) for Secure Transport
draft-hy-gue-4-secure-transport-01
Abstract
This document specifies use of generic UDP encapsulation (GUE) [GUE]
to provide secure transport over IP networks and Internet, including
use of IPSEC with GUE and methods to provide integrity and
authentication of the GUE header.
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 6, 2015.
Copyright Notice
Copyright (c) 2015 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 2015
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. Generic UDP Encapsulation (GUE) for Secure Transport...........3
4. Encapsulation/Decapsualtion Operation..........................5
5. Security Considerations........................................6
5.1. GUE and IPsec.............................................6
5.2. GUE security field use....................................7
5.2.1. Cookies..............................................7
5.2.2. Secure hash..........................................7
6. IANA Considerations............................................7
7. References.....................................................7
7.1. Normative References......................................7
7.2. Informative References....................................8
8. Authors' Addresses.............................................8
Yong & Herbert [Page 2]
Internet-Draft GUE for Secure Transport March 2015
1. Introduction
This document specifies use of generic UDP encapsulation (GUE) [GUE]
to provide secure transport over IP networks and Internet, including
use of IPSEC with GUE and methods to provide integrity and
authentication of the GUE header.
Secure transport over IP networks is extremely important for many
applications in IP networks. Tunnel mechanisms can be used to
provide secure transport for some network protocols over IP
networks. For example: IPsec [RFC4301], L2TP [RFC3931].
This draft specifies GUE security capability to tunnel a network
protocol/application over IP networks. This security capability also
offers option feature to GUE applications such as Network
virtualization overlay [GUE4NVO] for secured transport.
The draft allocates two flag bits from GUE undefined flag bits for
Security purpose. Security field usage and key management, etc. is
expected to be negotiated out of band between two tunnel end points.
2. Terminology
The terms defined in [RFC768] 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. Generic UDP Encapsulation (GUE) for Secure Transport
GUE [GUE] defines a generic GUE header that applies any UDP tunnel
application. GUE header contains some key fields that a UDP tunnel
application needs. These key fields are version, control message
indication (c), Header Length (HLen), and Protocol Type (or ctype).
It also contains some undefined flags for a UDP tunnel application
to specify.
Yong & Herbert [Page 3]
Internet-Draft GUE for Secure Transport March 2015
This document proposes to allocate two flag bits from GUE undefined
flags for GUE to provide secure transport to a tunneled protocol.
This secure transport feature can apply to a GUE application when it
is necessary. GUE format with Security Flag is shown in figure 1.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 |C| Hlen | Proto/Ctype |V|SEC| Undefined Flags |E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Network ID (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Field ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 GUE Format with Security Flag
o 'V' Virtualization flag: This flag is designated for network
virtualization overlay (NVO). When set, Security field appear
after that; when clear, security field appear after GUE header.
To tunnel a protocol for secure transport, this flag MUST be
clear. NVO may utilize secure transport [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 communicating hosts. Potential uses of the
security field are discussed in 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
Yong & Herbert [Page 4]
Internet-Draft GUE for Secure Transport March 2015
The usage of the key fields in the GUE header [GUE] for secure
transport is described as below:
o Type: Set to 0x0 for secure transport.
o Control flag: When it set, control message presents and control
processing MUST occur after security validation.
o Hlen: summary of optional fields (byte)/4
o Protocol: Contain the protocol of the encapsulated payload packet,
i.e. next header. The next header begins at the offset provided
by Hlen.
o CType: N/A
o '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 usage for secure transport: 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].
4. Encapsulation/Decapsualtion Operation
GUE secure transport 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). To tunnel a protocol for secure
transport, tunnel ingress and egress MUST compliant GUE header
process precedence specified in [GUE]. At tunnel egress, the payload
processing MUST be done after security validation
For a GUE application, secure transport is an option feature. When
it is used, the flag MUST be set and the security field is placed in
the optional fields. The GUE application MUST specify use of this
option.
See Section 5 for Security field encoding.
Yong & Herbert [Page 5]
Internet-Draft GUE for Secure Transport March 2015
5. Security Considerations
Encapsulation of IP protocols within GUE should not increase
security risk, nor provide additional security in itself. As
suggested in section 3 the source port for of UDP packets in GUE
should be randomly seeded to mitigate some possible denial service
attacks.
GUE is most useful when it is in the outermost header of a packet
which allows for flow hash calculation as well as making GUE data
(such as virtual network identifier) visible to switches and
middleboxes. GUE must be amenable to encapsulating (and being
encapsulated) within IPsec. Also, we allow provisions to secure the
GUE header itself without external protocol.
5.1. GUE and IPsec
GUE may be used to encapsulate IPsec packets. This allows the
benefits of deriving a flow hash for the inner, potentially
encrypted, packet. In this case the protocol stack may be:
+-------------------------------+
| |
| UDP/IP header |
| |
|-------------------------------|
| |
| GUE Header |
| |
|-------------------------------|
| |
| ESP/AH/private security |
| |
|-------------------------------|
| |
| Encapsulated packet |
| |
+-------------------------------+
Note that the security does not cover the GUE header (does not
authenticate it for instance). The GUE security field may be used to
provide authentication or integrity of the GUE header.
Yong & Herbert [Page 6]
Internet-Draft GUE for Secure Transport March 2015
5.2. GUE security field use
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.
5.2.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 might
have different cookies.
5.2.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
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.
6. IANA Considerations
The document does not require any IANA action.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
Yong & Herbert [Page 7]
Internet-Draft GUE for Secure Transport March 2015
[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
[GUE] Herbert, T., and Yong, L., "Generic UNP Encapsulation", draft-
herbert-gue-03, work in progress.
7.2. Informative References
[GUE4NVO] Yong, L., and Herbert T., "Generic UNP Encapsulation for
NVO", draft-hy-nov3-gue-4-nvo-01, work in progress.
8. Authors' Addresses
Lucy Yong
Huawei USA
5340 Legacy Dr.
Plano, TX 75024
US
Email: lucy.yong@huawei.com
Tom Herbert
Google
1600 Amphitheatre Parkway
Mountain View, CA
US
Email: therbert@google.com
Yong & Herbert [Page 8]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/