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: 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: 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: 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: 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: 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: Server to client direction: If dst-port-tuples are in use (B bit not set), a stateful firewall would create filters: Client to server direction: Server to client direction: 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: <-> Client to server tuple before NAT: Client to server tuple after NAT: 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 Server to client tuple after return through NAT: 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: <-> Client to server tuple before NAT: Client to server tuple after NAT: Server to client before return through NAT: Server to client tuple after return through NAT: 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, . [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]