Internet DRAFT - draft-herbert-gue-session-id
draft-herbert-gue-session-id
INTERNET-DRAFT T. Herbert
Intended Status: Proposed Standard Facebook
Expires: November, 2015 L. Yong
Huawei
May 22, 2015
Session Identifier Option for Generic UDP Encapsulation
draft-herbert-gue-session-id-00
Abstract
This specification defines the session identifier option for Generic
UDP Encapsulation (GUE). This option allows an encapsulator to
identify a logical session to which an encapsulated packet belongs.
The session for a packet may refer to the flow or connection of an
encapsulated transport protocol, and the session identifier option
provides visibility into this at the encapsulation layer. Nodes may
use the session identifier option to create and maintain session
state for encapsulated flows, and in turn can affect packet
processing on the basis of this state.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
Herbert, Yong Expires November, 2015 [Page 1]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
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 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Option format . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Initiator and target roles . . . . . . . . . . . . . . . . . 6
3.2 Session tuples . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1 Both-port-tuples . . . . . . . . . . . . . . . . . . . . 7
3.2.2 Dst-port-tuples . . . . . . . . . . . . . . . . . . . . 7
3.3 Matching packets to sessions . . . . . . . . . . . . . . . . 7
3.3.1 Both-port-tuple matching . . . . . . . . . . . . . . . . 8
3.3.2 Dst-port-tuple matching . . . . . . . . . . . . . . . . 8
3.5 Session types . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Session commands . . . . . . . . . . . . . . . . . . . . . . 9
3.5 Session state machines . . . . . . . . . . . . . . . . . . . 9
3.6 Session state errors . . . . . . . . . . . . . . . . . . . . 10
4 Types of sessions . . . . . . . . . . . . . . . . . . . . . . . 10
4.1 Unattached . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Unidirectional . . . . . . . . . . . . . . . . . . . . . . . 11
4.3 Bidirectional . . . . . . . . . . . . . . . . . . . . . . . 12
4.4 Transactional . . . . . . . . . . . . . . . . . . . . . . . 16
5 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1 Session state maintainers . . . . . . . . . . . . . . . . . 18
5.1.1 UDP transport protocols . . . . . . . . . . . . . . . . 18
5.1.2 Tunnel endpoints . . . . . . . . . . . . . . . . . . . . 18
5.1.3 Middleboxes . . . . . . . . . . . . . . . . . . . . . . 18
5.2 Encapsulator operation . . . . . . . . . . . . . . . . . . . 18
5.3 Decapsulator operation . . . . . . . . . . . . . . . . . . . 19
5.4 Middlebox operation . . . . . . . . . . . . . . . . . . . . 19
5.5 Simultaneous opens . . . . . . . . . . . . . . . . . . . . . 19
6 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1 Mapping a TCP connection to a session . . . . . . . . . . . 20
6.2 Stateful firewalls . . . . . . . . . . . . . . . . . . . . . 21
Herbert, Yong Expires November, 2015 [Page 2]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
6.3 Stateful NAT . . . . . . . . . . . . . . . . . . . . . . . . 22
6.3.1 NAT with both-port-tuple sessions . . . . . . . . . . . 22
6.3.2 NAT dst-port-tuple sessions . . . . . . . . . . . . . . 23
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 24
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 24
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1 Normative References . . . . . . . . . . . . . . . . . . . 24
9.2 Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Herbert, Yong Expires November, 2015 [Page 3]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
1 Introduction
This document specifies the session identifier option in Generic UDP
Encapsulation ([I.D.herbert-gue]). This option allows an encapsulator
to identify a logical session to which an encapsulated packet
belongs. A session may refer to a connection or flow in the
encapsulated communication, or may act as a transaction identifier in
a request/reply type of communication.
Decapsulators may use this option to assist in steering packets for
processing (to the proper application socket for instance).
Middleboxes may use this information to establish a flow state for
the underlying communication such as might be done in implementing a
stateful firewall.
The option includes commands from which session state may be derived.
A state machine can be implemented that takes these commands as input
and provides orderly transitions for creating a session state,
permitting communication over the session, and then destroying the
state when the session is complete.
This design borrows many concepts from the SPUD prototype protocol
([I.D.hildebrand-spud-prototype]).
1.1 Terminology
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 RFC 2119 [RFC2119].
2 Option format
The session identifier is sent in an optional field in the GUE
header. The format of the session identifier optional 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stype | Scmd |I|B|W| Reserved| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are:
o Stype: Session type. See below
Herbert, Yong Expires November, 2015 [Page 4]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
o Scmd: Session command. See below
o I: Initiator bit. When set indicates the source address of the
packet is the initiator and the destination address is the
target of the related session. When not set indicates that the
source address is the target and the destination address is the
initiator.
o B: Both ports bit. When set indicates that the UDP source port
is considered part of the session tuple. This is used to
distinguish between both-port-tuples and dst-port-tuples (see
below)
o W: Writeable bit. Indicates that a middlebox may rewrite the
session identifiers to implement stateful NAT
o Session Identifier: Indicates the session identifier value. This
is set per the session types described below
The format of the session identifier option within the GUE and UDP
header is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source port | Destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0x0|C| Hlen | Proto/ctype |V|SEC|K|F|T|S| Flags |E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ VNID, security, checksum, fragmentation fields (optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stype | Scmd |I|B|W| Reserved| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
| Session identifier |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension flags(optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Extension fields (optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Herbert, Yong Expires November, 2015 [Page 5]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
The fields in the GUE header that are pertinent to the session
identifier option are:
o C: Indicates presence of a control message or data message. The
session identifier may be used with either message type. The C
bit is not used to distinguish between sessions and is not part
of a session tuple.
o V: Virtual networking identifier (VNID) is present. The VNID may
be present but is not included in the session tuple.
o S: GUE header flag that indicates presence of the session
identifier option.
3 Sessions
The session identifier option may be used to indicate a session
between end points. The figure below provides a reference topology
for the session interaction between two end hosts and a middlebox.
+------------+ +------------+ +------------+
| | | | | |
| Host A |-//-| Middlebox |-//-| Host B |
| | | | | |
+------------+ +------------+ +------------+
3.1 Initiator and target roles
Sessions are initiated from one end point of the communication. The
end point which initiates the session is the initiator, and its peer
is the target. For instance, if Host A initiates a session with Host
B, Host A is the initiator and Host B is the target.
The initiator bit in the session identifier option indicates that the
sender (source address) is the initiator of the session. The bit is
set for packets that flow from the initiator to the target, and not
set for packets in the reverse direction when using bidirectional
sessions. The initiator bit must be set properly by each side for the
full lifetime of the session.
3.2 Session tuples
The unique identification of a session is provided in an n-tuple that
is referred to as the session tuple. The session tuple includes the
session identifier value, the IP address of the initiator, the IP
address of the target, and the destination port used by the
initiator. The initiator source port may optionally be included in
the session tuple.
Herbert, Yong Expires November, 2015 [Page 6]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
The general form of a session tuple is:
<Init_Addr, Targ_Addr, {Init_src_port}, Init_dst_port,
Session_identifier>
A both-port-tuple is a session tuple that includes the UDP source
port, a dst-port-tuple is one that does not.
3.2.1 Both-port-tuples
When the source port is included in the session tuple (the B bit in
the session identifier option is set) then the session tuple where A
is the initiator and B is the target is:
<Addr_A, Addr_B, Port_A, Port_B, Session_identifier>
Where Port_A and Port_B are the source and destination ports used by
the initiator (Host A).
3.2.2 Dst-port-tuples
If the source port is not used as part of the session tuple (the B
bit is not set in the session identifier option) then the session
tuple where A is the initiator and B is the target is:
<Addr_A, Addr_B, Dst_port, Session_identifier>
Where Dest_port is the listener port on the target for the GUE
encapsulation.
3.3 Matching packets to sessions
Sessions may be unidirectional where packets for the session only
flow from the initiator to the target, or may be bidirectional
allowing packet flow in both directions. Whether a session is
unidirectional or bidirectional is indicated in the session type that
is set by the initiator.
The session identifier is set by the initiator for unidirectional
sessions. For bidirectional sessions, the field is split into a
initiator and target component where each side contributes a value
for their respective component. Both the intiator and that target set
the same value in the session identifier for packets sent on the
session except in the case of an open command for a bidirectional
session (see below).
Received GUE packets with the session identifier option are matched
to sessions using packet matching rules. For a unidirectional
Herbert, Yong Expires November, 2015 [Page 7]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
session, packets need to only matched in one direction requiring one
packet matching rule, for a bidirectional session two are required.
The matching rules are also different if the session is identified by
both-port-tuple or dst-port-tuple.
3.3.1 Both-port-tuple matching
For a both-port-tuple (B bit is set), connection-like semantics are
applied to the UDP tuple where both the IP addresses and ports are
swapped between the two directions of communication. The both-port-
tuple for a session between initiator A and target B, is:
<Addr_A, Addr_B, Port_A, Port_B, Session_identifiers>
Packets in the session sent from A to B are matched by:
Source address = Addr_A
Destination address = Addr_B
Source port = Port_A
Destination port = Port_B
Session identifier = Session_identifier
Initiator (I bit) is set
Use source port (B bit) is set
Packets in the session sent from B to A are matched by:
Source address = Addr_B
Destination address = Addr_A
Source port = Port_B
Destination port = Port_A
Session identifier = Session_identifier
Initiator (I bit) is not set
Use source port (B bit) is set
3.3.2 Dst-port-tuple matching
For a dst-port-tuple (B bit is not set) it is assumed that the
destination port is the same in both directions of a bidirectional
session. The dst-port-tuple for a session between A and B where A is
the initiator would be:
<Addr_A, Addr_B, Dest_port, Session_ID>
Packets in the session sent from A to B are matched by:
Source address = Addr_A
Destination address = Addr_B
Destination port = Dest_port
Herbert, Yong Expires November, 2015 [Page 8]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
Session identifier = Session_identifier
Initiator (I bit) is set
Use source port (B bit) is not set
Packets in the session sent from B to A are matched by:
Source address = Addr_B
Destination address = Addr_A
Destination port = Dest_port
Session identifier = Session_identifier
Initiator (I bit) is not set
Use source port (B bit) is not set
3.5 Session types
The session identifier option allows different types of sessions with
different semantics. The Stype field in the option indicates the
session type. The session type is initially set by the initiator and
must be used for all packets for the session. The defined session
types are described in section 4.
3.4 Session commands
Session commands are sent by an initiator and target to indicate
transitions in the state of a session. The commands are sent based on
the transitions in an underlying encapsulated transport protocol. The
Scmd field in the session identifier option holds the session command
for a packet. The session commands are specific to the session type
for which they are applied (value in the Stype field).
3.5 Session state machines
Each session type defines a state machine that describes the lifetime
of the session from opening to closing. A set of session specific
commands provide input to making state transitions.
The Init state is the default initial state for all sessions. This is
a virtual state for sessions in which no real state exists. The Init
state is represented in each of the session type state machines. A
session command may move the session out of Init state and into a
state specific to the corresponding session type.
The Closing state is common to all the session types except
Unattached. When a close command is seen for a session, a timeout
occurs in a session state, or there is session state error then
session state transitions to Closing. Closing state should implement
a hold down timer so that any outstanding packets seen with the same
session tuple do not cause a new session to be opened. This is
Herbert, Yong Expires November, 2015 [Page 9]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
roughly equivalent to TIME_WAIT state in TCP.
If a state machine is being implemented in a node which is inferring
actions from packets received (as opposed to working in direct
conjunction with the underlying transport protocol) then session
states may include a timeout. A timeout would be set upon entering a
state (other than Established, Init, or Closing) and would be
canceled when a state transition happens. If a timeout occurs, then
the state should transition to Closing.
A keepalive timer may be used in an Established state. Whenever data
is seen on the session, the timer is reset. If the timer expires the
session should move to Closing state. In bidirectional sessions,
acknowledgments (ack command) may be used to indicate that new data
is being acked by an endpoint as an indication that forward progress
is being made in an underlying transport.
3.6 Session state errors
If a packet is received that has a different session type then that
in the recorded state for the session or receives an unknown command
for the session, these are considered session state errors. The
default behavior in these cases is to move to Closing state.
4 Types of sessions
The session types are:
o Unattached (0)
o Unidirectional (1)
o Bidirectional (2)
o Transactional (3)
4.1 Unattached
Unattached sessions are effectively "null" sessions. These allow use
of the session identifier without implying that any session state is
created. There are no session type specific states.
Session type:
Stype = 0
Herbert, Yong Expires November, 2015 [Page 10]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
Session commands:
o data (0): Data packet (only valid command)
State machine:
+-------------+
| Init |<---+
+-------------+ |
| |
data |
| |
+------------+
Session identifiers:
The initiator selects the session identifier for each packet.
There no are semantics associated with the session identifier for
unattached sessions.
4.2 Unidirectional
In a unidirectional session, packets only flow from the initiator to
the target in a single direction. Responses in an underlying
transport protocol from a target back to an initiator can be sent
using a different session. For a unidirectional session the target
may be a multicast address.
Session type:
Stype = 1
Session commands:
data (0): Data packet in session. Provides implicit open for a
new session
close (1): Close session (only sent by the initiator).
Session states:
o Init: Default initial state for all session types
o Closing: Common closing state for sessions
o Opened: Session is opened with first data command.
Communications over the session can proceed
Herbert, Yong Expires November, 2015 [Page 11]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
State machine:
+-------------+ +-------------+
| Init |<-(timeo)-| Closing |<----+
+-------------+ +-------------+ |
| ^ | |
+-----+ data | data,close |
| | | | | |
data v v | +----------+
| +-----------+ |
+--| Opened |--close--------+
+-----------+
Session identifiers:
The sender selects the session identifier when first sending data
on a new session. The same value must be used for all packets sent
on the session.
4.3 Bidirectional
Bidirectional sessions allow packet flow in both directions. The
negotiation of a bidirectional session follows a 2-way or 3-way
handshake where both sides may acknowledge the opening of a session
(similar to TCP connection set up).
Session type:
o Stype = 2
Session commands:
o open (0): Request to open a bidirectional session. Only sent by
an initiator
o ack (1): Acknowledgment that can be sent by either side.
Before a session is in Established state this is used
by a side to acknowledge the opening of the session.
In Established state, acknowledgments can be used to
indicate that new data has been received by the
underlying protocol
o xack (2): Fast acknowledgment only sent by the target to
acknowledge a connection initiation. This implies
two-way handshake is sufficient to establish a
session (similar to TCP fast open)
o close (3): Close session. Can be be sent by the target or
Herbert, Yong Expires November, 2015 [Page 12]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
initiator
o data (4): Used for other all other packets on the session
Session states:
o Init: Default initial state for all session types
o Opening: An open command has been seen as first command for the
session
o Closing: Common closing state for sessions
o Tacked: An open command and a target acknowledgment of opening
the session have been seen
o Established: Session negotiation is complete from both sides
o Rdata: Data command seen before any other command for the
session
o RIacked1: An acknowledgment from the initiator has been seen
before an open command
o RIacked2: An open command and an initiator acknowledgment have
been seen before a target acknowledgment
o RTacked: An acknowledgment from the target has been seen before
an open command
o RTIacked: acknowledgments from both sides have been seen before
an open command
Herbert, Yong Expires November, 2015 [Page 13]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
State machine:
+-------------------------------------------+ ANY STATE
| +-------------+ +-------------+ | |
| | Rdata |<--data--| Init |<-(timeo)-+ close
| +-------------+ +-------------+ | | |
+-------------------------------------------+ | v
| | | | +-------------+
| | | | | Closing |
| | | +--tack-----+ +-------------+
open iack | |
| | +--xack----+ |
v v | v
+----------------+ +---------------+ | +-------------+
| Opening | | RIacked1 | | | RTacked |
+----------------+ +---------------+ | +-------------+
| | | | | | | |
tack | +-iack-+ open tack,xack | iack,xack |
| +-xack-+ | | | | | |
v | v v v v v |
+------------+ | +--------------+ +------------------+ |
| Tacked | | | RIacked2 | | RTIacked | open
+------------+ | +--------------+ +------------------+ |
^ | | | | |
| iack,xack | tack,xack open |
| | | | | |
| | | | +-------------+ | |
| +--------+-------+-->| Established |<---+ |
| +-------------+ |
+----------------------------------------------------------+
Session identifiers:
The session identifier is split into an initiator and target
component. The format of the session identifier for a
bidirectional session is:
0 1 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Session Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Session Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The procedures for setting the session identifier are:
o The initiator sets the Initiator Session Identifier in all
Herbert, Yong Expires November, 2015 [Page 14]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
packets sent to the target. The target reflects this value. The
Initiator Session Identifier sent with a zero Target Session
Identifier must make a unique session tuple.
o The target sets the Target Session Identifier in all packets
sent to the initiator. The value must be chosen to create a
unique session tuple.
o When an initiator sends an open command the Target Session
Identifier must be set to zero.
o When a target receives a valid open command for a new session,
it saves the Initiator Session Identifier and reflects it in any
subsequent packets sent the initiator.
o In opening state an initiator matches packets from the target
based only on the Initiator Session Identifier.
o When a valid ack is received in Opening state, the initiator
saves the Target Session Identifier. It reflects the value in
any subsequent packets sent to the target and includes in it
matching the session tuple for packets received from the target.
Notes:
o The R* session states are those where commands have been
received out of the nominal order. These states are applicable
in a middlebox which is inferring state from received packets.
o iack refers to an acknowledgment (ack command) sent by the
initiator
o tack refers to an acknowledgment (ack command) sent by the
target
o ANY STATE refers to any bidirectional state and the common Init
state. When a close is seen from either side, a transition to
Closing is done
o For any actions (session commands) not listed in the state
machine, the default behavior is that the action is valid and
does not change state.
o If a target sends an open command this is considered a session
state error, the session state should transition to Closing
o If an initiator sends an xack command this is considered a
session state error, the session state should transition to
Herbert, Yong Expires November, 2015 [Page 15]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
Closing
4.4 Transactional
A transactional session is created to perform a request/response type
of communication. The initiator makes a request, and the target is
expected to reply. The target typically will send a close command in
the last packet of the reply. An initiator may send more than one
transaction over a session.
Session type:
Stype = 1
Session commands:
o req (0): Request sent by the initiator. Used with multiple
transactions in a session to indicate more requests
are coming
o freq (1): Final request sent by initiator. Packets that are
part of the final request (or only request) should
use the freq command
o rep (2): Reply from the target
o close (3): Close session. Can be be sent by the target or
initiator
Session states:
o Init: Default initial state for all session types
o Closing: Common closing state for sessions
o Requesting: A request from initiator has been seen
o Replying: A request from initiator and a reply from the target
have been seen
o Requested: A final request has been seen from initiator
o Replied: A final request has been seen from initiator and a
reply from the target
o Rreplying: A reply has been seen from the target before a
request. This implies that the reply has been received out of
order
Herbert, Yong Expires November, 2015 [Page 16]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
State machine:
+-----------------+ +-------------+
| Init |<--timeo--| Closing |<-+
+-----------------+ +-------------+ |
| | | |
+--req--+ freq +-------rep-------+ |
| | | ANY STATE
v v v
+-------------+ +--------------+ +--------------+
| Requesting |--freq-->| Requested | | Rreplying |
+-------------+ +--------------+ +--------------+
| | | |
rep rep freq |
| | | req
v v | |
+-------------+ +--------------+ | |
| Replying |--freq-->| Replied |<----+ |
+-------------+ +--------------+ |
^ |
| |
+--------------------------------------------+
Notes:
o ANY STATE refers to any transactional state and the common Init
state. When a close is seen from either side, a transition to
closing is done
o For any actions (session commands) not listed in the state
machine, the default behavior is that the action is valid and
does not change state.
o If an initiator sends a req command this is considered a session
state error; the session state should transition to Closing
o If a target sends a req or freq command this is considered a
session state error; the session state should transition to
Closing
Session identifiers:
The sender selects the session identifier when first sending
request on a new session. The target must reflect the value in
reply messages. The same session identifier value must be used for
all packets sent on the session.
5 Operation
Herbert, Yong Expires November, 2015 [Page 17]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
5.1 Session state maintainers
Sessions are typically created and maintained on the basis of an
underlying transport protocol which is being encapsulated. Session
commands are usually generated by an encapsulator based on
transitions in the underlying protocol.
There are three points at which session state may be maintained
o UDP transport protocols
o Tunnel endpoints
o Middleboxes
5.1.1 UDP transport protocols
For UDP transport protocols, sessions can be tightly coupled with the
transport protocol, or possibly directly used as the representation
of an endpoint within the transport protocol. Session commands are
generated from the transport protocol, and the session state on a
node implementing the transport protocol may be implicitly derived
from the transport state.
5.1.2 Tunnel endpoints
For tunnel endpoints, a typical model would be to map transport layer
connections for packets entering the tunnel into session state and
commands. This will typically entail parsing the transport protocol
of packets and deducing session state for them. When the packets are
encapsulated, the session type and commands are set accordingly.
5.1.3 Middleboxes
In a middlebox session state may be created and maintained per the
the information in the session identifier option for packets seen. A
middlebox is expected to parse only the session identifier option to
infer session state, it does not need to parse the packet to extract
information about the underlying transport protocol (in fact if the
payload is encrypted it is not possible to parse the encapsulated
transport protocol).
5.2 Encapsulator operation
An encpasulator may set the session identifier option in a GUE
packet. The session commands in option may be used to provide signals
to the network or decapsulator for the creation and closing of the
session.
Herbert, Yong Expires November, 2015 [Page 18]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
The B bit must be set consistently for a session. Its use depends on
the underlying transport layer protocol and configuration.
The I bit must be set consistently for a session. This is always set
in a packet sent by the initiator of a session, and unset for packets
sent by a target.
The W bit should not be set when the GUE security option is also
used.
The session type must be set to the same value for packets in a
session.
5.3 Decapsulator operation
A decapsulator must process the session identifier option when it is
present. It may use the information to maintain session state for the
session.
The session information in the session identifier may be directly
used as the endpoint identifier of a UDP transport protocol. In this
case, the session option should be appropriately validated for
integrity. This can be provided by the GUE security option or by
validation information contained in the encapsulation payload.
If the B bit is set, the decapsulator must use the both-port-tuple
for matching state, else it must use the session dst-port-tuple.
5.4 Middlebox operation
A middlebox may optionally process a session identifier option. A
middlebox may create and track sessions based on the session
identifier option.
A middlebox must not modify the session identifier option in packets
including the session command and session type. The exception is that
session identifiers can be modified to implement stateful NAT. If the
W (writeable) bit is set, then a middlebox may rewrite the session
identifier. When a middlebox changes the session identifier in a
packet it must update the UDP checksum and GUE header checksum
([I.D.herbert-gue-csum]) if these have been enabled.
5.5 Simultaneous opens
An encapsulated transport protocol, such as TCP, may allow
simultaneous opens. With bidirectional sessions each side may send
open commands on different sessions for the same connection. One of
the sessions should be elected as the primary session to be used and
Herbert, Yong Expires November, 2015 [Page 19]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
the other should be closed by its initiator. The procedure for
deciding the primary session should be done in the context of the
transport protocol with prior agreement between the endpoints. This
can be accomplished by comparing fields in the transport protocol
packet (not affected by NAT). For instance, in TCP the session for
which the initiator sent the greater sequence number could be chosen
as the primary session.
6 Use cases
This specification describes the session identifier option and
session state maintenance, however it does not specify how sessions
are created and who generates commands. Neither does it specify the
affect on packet processing associated with session states. Both of
these should be defined for particular applications of the session
identifier option. For instance a firewall might only allow packets
to flow through it when sessions have been created and reached an
appropriate state.
This section provides some general guidance on mapping connections to
a session, and session processing for stateful firewalls and NAT.
6.1 Mapping a TCP connection to a session
As an example implementation of sessions, consider that the session
identifier option is used at the endpoints of an IP tunnel and the
underlying transport protocol of interest is TCP. In this case
session commands could be used to reflect the state of the TCP
connection in the session identifier option. State transitions for a
TCP connection would be mapped to session commands.
Suppose that Host A opens a TCP connection to Host B over a GUE
tunnel with the session identifier option in use. A is the initiator
of a session and B is the target. Host A selects an Initiator session
identifier for the TCP connection and we assume session type is
bidirectional.
The packet sequence and state transitions in both the TCP state
machine and the session state machine might be:
A sends initial SYN to B, session command "open" is set
TCP state on A moves to SYN-SENT
TCP state on B moves to SYN-RECV
Session state moves to "Opening" based on open command
B replies to A with a SYN-ACK, session command "ack" is set
TCP state on A moves ESTABLISHED
TCP state on B moves to SYN-RECV
Herbert, Yong Expires November, 2015 [Page 20]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
Session state moves to "Tacked" based on tack action
A acknowledges the SYN, session command "ack" is set
TCP state on A is ESTABLISHED
TCP state on B moves to ESTABLISHED
Session state moves to "Established" based on iack action
Once the TCP connection is established, packets on the connection
would be sent using the data command for the session. The ack command
might also be used with TCP acknowledgments of new data.
The close command would be used when one side has sent a FIN and
sends an ACK for the FIN from the peer. This happens with either the
TCP state transition from FIN_WAIT_1 or FIN_WAIT_2 to TIME_WAIT, or
from LAST_ACK to CLOSED. The close command should also be used when a
TCP Reset is sent. When a close is seen for a session, the session
state moves to Closing for any state. Both sides may send a close
command for the same session, only one is needed to move the session
to Closing so the second one does not impact state.
6.2 Stateful firewalls
In a stateful firewall, two matching filters are created for a flow
going through the firewall-- one for each direction. In the classical
model, a client initiates a connection (e.g. by sending TCP-SYN). A
firewall will observe this connection request and will create a flow
state that matches packets in both directions of the flow-- that is a
filter for packets from the client to server, and a filter for
packets from server to the client where the source and destination
addresses and ports are swapped. This works with connection oriented
transport protocols such as TCP, however for a connectionless
protocol such as UDP it is not guaranteed that the four tuples of
packets are symmetric and UDP does not include information that can
be used to infer connection state.
The session identifier option may be used to allow middleboxes to
infer flow states for a stateful firewall with UDP flows. As an
example, consider that a client initiates a TCP connection to a
server over which goes over a GUE tunnel. Encapsulated packets would
have the form: IP|UDP|GUE|IP|TCP. The session identifier option will
be present in the GUE header where the session identifier is set to
create a unique session. The TCP flags (SYN, FIN, and ACK) would be
mapped to the session commands in the session identifier option as
demonstrated above.
If the session both-port-tules are in use (B bit is set in the
session identifier option) then connection semantics may be assumed
for UDP. A stateful firewall would create filters:
Herbert, Yong Expires November, 2015 [Page 21]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
Client to server direction:
<Addr_A, Addr_B, Port_A, Port_B, Session_identifier>
Server to client direction:
<Addr_B, Addr_A, Port_B, Port_A, Session_identifier>
If dst-port-tuples are in use (B bit not set), a stateful firewall
would create filters:
Client to server direction:
<Addr_A, Addr_B, *, Dest_port, Session identifier>
Server to client direction:
<Addr_B, Addr_A, *, Dest_port, Session identifier>
The filters allow packets to flow and would remain in place until the
session is closed.
6.3 Stateful NAT
NAT is similar to the stateful firewalls described above but needs
additional considerations particularly when address translation is
performed on the source address of packet.
6.3.1 NAT with both-port-tuple sessions
In the case of both-port-tuple sessions (B bit is set), port and
address translation should work based on the NAT address/port
translation:
Translations:
<Addr_A, Port_A> <-> <Addr_X, Port_X>
Client to server tuple before NAT:
<Addr_A, Addr_B, Port_A, Port_B, Session_identifier>
Client to server tuple after NAT:
<Addr_X, Addr_B, Port_X, Port_B, Session identifier>
Server to client tuple before return through NAT:
Herbert, Yong Expires November, 2015 [Page 22]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
<Addr_B, Addr_X, Port_B, Port_X, Session identifier>
Server to client tuple after return through NAT:
<Addr_B, Addr_A, Port_B, Port_A, Session identifier>
6.3.2 NAT dst-port-tuple sessions
When using dst-port-tuple sessions the UDP source port is not
considered relevant to identifying a flow. The source port is not
used as the destination port in the reverse path, so it's not
meaningful to create a NAT state that maps the destination port to an
original source port. To facilitate address translation the session
identifier can be translated in a manner similar to that of source
port translation in normal NAT. NAT translation of address/session
identifier would be:
Translations:
<Addr_A, Session_identifier> <-> <Addr_X, Session_identifier_X>
Client to server tuple before NAT:
<Addr_A, Addr_B, *, Dest_port, Session_identifier>
Client to server tuple after NAT:
<Addr_X, Addr_B, *, Dest_port, Session_identifier_X>
Server to client before return through NAT:
<Addr_B, Addr_X, *, Dest_port, Session_identifier_X>
Server to client tuple after return through NAT:
<Addr_B, Addr_A, *, Dest_port, Session_identifier>
Note that since the Dest_port is common to both sides in a dst-port-
tuple session this NAT translation is symmetric from both the
initiator and target sides.
Herbert, Yong Expires November, 2015 [Page 23]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
7 Security Considerations
The session identifier option does not provide any security or
validation in itself, however it may expose information about an
encapsulated flow (for instance the GUE payload may be encrypted by
DTLS). Security should be considered in both the possible inference
of information from the session identifier option, as well as the
integrity and authenticity of the option.
The information exposed by the session identifier is mostly session
state information which should mostly be innocuous (for instance TCP
flags are always visible in current use of TLS over TCP). The session
identifiers should be chosen to prevent inference of any useful
information to an attacker, for instance the identities of the users
of the encapsulation should not be deducible from the session
identifiers.
Session identifiers must not be predictable in order to thwart DDOS
or other attacks. A host must use a random seed for generating
identifiers.
To protect the integrity of the session identifier GUE header
security ([I.D.hy-gue-4-secure-transport]) may be used. GUE security
is end to end, so middleboxes will not be able to validate the
option. Note that if the middlebox is permitted to modify the session
identifier option, as in the case of stateful NAT with session dst-
port-tuples, then the header security is not usable. An encapsulated
transport protocol may provide its own mechanisms to validate the
packet including the GUE header and the session identifier option.
8 IANA Considerations
The session identifier option defines one flag bit in the GUE header
and a corresponding 96-bit field.
9 References
9.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[I.D.herbert-gue] T. Herbert, L. Yong, and O. Zia, "Generic UDP
Encapsulation" draft-herbert-gue-03
9.2 Informative References
Herbert, Yong Expires November, 2015 [Page 24]
INTERNET DRAFT Session Identifier Option for GUE May 22, 2015
[I.D.hildebrand-spud-prototype] J. Hildebrand and B. Trammell,
"Substrate Protocol for User Datagrams (SPUD) Prototype"
draft-hildebrand-spud-prototype-03
[I.D.hy-gue-4-secure-transport] L. Yong and T. Herbert, "Generic UDP
Encapsulation (GUE) for Secure Transport" draft-hy-gue-4-
secure-transport-01
[I.D.hy-nvo3-gue-4-nvo] Yong, L., Herbert, T., "Generic UDP
Encapsulation (GUE) for Network Virtualization Overlay",
work in progress
[I.D.herbert-gue-csum] T. Herbert, "Checksum option for Generic UDP
Encapsulation", draft-herbert-guecsum-00
[I.D.hy-gue-4-secure-transport] L. Yong and T. Herbert, "Generic UDP
Encapsulation (GUE) for Secure Transport" draft-hy-gue-4-
secure-transport-01
Authors' Addresses
Tom Herbert
Facebook
Menlo Park, CA
US
EMail: tom@herbertland.com
Lucy Yong
Huawei USA
5340 Legacy Dr.
Plano, TX 75024
US
Herbert, Yong Expires November, 2015 [Page 25]
