Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7016

Adobe's Secure Real-Time Media Flow Protocol

Pages: 113
Informational
Part 3 of 4 – Pages 45 to 75
First   Prev   Next

Top   ToC   RFC7016 - Page 45   prevText

3. Operation

3.1. Overview

+--------+ +--------+ | Peer A | S E S S I O N | Peer B | | /=============================\ | | || Flows || | | ||---------------------------->|| | | ||---------------------------->|| | | ||<----------------------------|| | | ||<----------------------------|| | | ||<----------------------------|| | | \=============================/ | | | | | | | +--------+ | | | | +--------+ | | S E S S I O N | Peer C | | /=============================\ | | || Flows || | | ||---------------------------->|| | | ||<----------------------------|| | | ||<----------------------------|| | | \=============================/ | | | | | +--------+ +--------+ Figure 7: Sessions between Pairs of Communicating Endpoints Between any pair of communicating endpoints is a single, bidirectional, secured, congestion controlled session. Unidirectional flows convey messages from one end to the other within the session. An endpoint initiates a session to a far end when communication is desired. An initiator begins with one or more candidate destination socket addresses, and it may learn and try more candidate addresses during startup handshaking. Eventually, a first suitable response is received, and that endpoint is selected. Startup proceeds to the selected endpoint. In the case of session startup glare, one endpoint is the prevailing initiator and the other assumes the role of responder. Encryption keys and session identifiers are negotiated between the endpoints, and the session is established. Each endpoint may begin sending message flows to the other end. For each flow, the far end may accept it and deliver its messages to the user, or it may reject the flow and transmit an exception to the
Top   ToC   RFC7016 - Page 46
   sender.  The flow receiver may close and reject a flow at a later
   time, after first accepting it.  The flow receiver acknowledges all
   data sent to it, regardless of whether the flow was accepted.
   Acknowledgements drive a congestion control mechanism.

   An endpoint may have concurrent sessions with other far endpoints.
   The multiple sessions are distinguished by a session identifier
   rather than by socket address.  This allows an endpoint's address to
   change mid-session without having to tear down and re-establish a
   session.  The existing cryptographic state for a session can be used
   to verify a change of address while protecting against session
   hijacking or denial of service.

   A sender may indicate to a receiver that some user messages are of a
   time critical or real-time nature.  A receiver may indicate to
   senders on concurrent sessions that it is receiving time critical
   messages from another endpoint.  The other senders SHOULD modify
   their congestion control parameters to yield capacity to the session
   carrying time critical messages.

   A sender may close a flow.  The flow is completed when the receiver
   has no outstanding gaps before the final fragment of the flow.  The
   sender and receiver reserve a completed flow's identifier for a time
   to allow in-flight messages to drain from the network.

   Eventually, neither end will have any flows open to the other.  The
   session will be idle and quiescent.  Either end may reliably close
   the session to recover its resources.

   In certain circumstances, an endpoint may be ceasing operation and
   not have time to wait for acknowledgement of a reliable session
   close.  In this case, the halting endpoint may send an abrupt session
   close to advise the far end that it is halting immediately.

3.2. Endpoint Identity

Each RTMFP endpoint has an identity. The identity is encoded in a certificate. This specification doesn't mandate any particular certificate format, cryptographic algorithms, or cryptographic properties for certificates. An endpoint is named by an Endpoint Discriminator. This specification doesn't mandate any particular format for Endpoint Discriminators. An Endpoint Discriminator MAY select more than one identity and MAY match more than one distinct certificate.
Top   ToC   RFC7016 - Page 47
   Multiple distinct Endpoint Discriminators MAY match one certificate.

   It is RECOMMENDED that multiple endpoints not have the same identity.
   Entities with the same identity are indistinguishable during session
   startup; this situation could be undesirable in some applications.

   An endpoint MAY have more than one address.

   The Cryptography Profile implements the following functions for
   identities, certificates, and Endpoint Discriminators, whose
   operation MUST be deterministic:

   o  Test whether a given certificate is authentic.  Authenticity can
      comprise verifying an issuer signature chain in a public key
      infrastructure.

   o  Test whether a given Endpoint Discriminator selects a given
      certificate.

   o  Test whether a given Endpoint Discriminator selects the local
      endpoint.

   o  Generate a Canonical Endpoint Discriminator for a given
      certificate.  Canonical Endpoint Discriminators for distinct
      identities SHOULD be distinct.  If two distinct identities have
      the same Canonical Endpoint Discriminator, an initiator might
      abort a new opening session to the second identity
      (Section 3.5.1.1.1); this behavior might not be desirable.

   o  Given a certificate, a message, and a digital signature over the
      message, test whether the signature is valid and generated by the
      owner of the certificate.

   o  Generate a digital signature for a given message corresponding to
      the near identity.

   o  Given the near identity and a far certificate, determine which one
      shall prevail as Initiator and which shall assume the Responder
      role in the case of startup glare.  The far end MUST arrive at the
      same conclusion.  A comparison function can comprise performing a
      lexicographic ordering of the binary certificates, declaring the
      far identity the prevailing endpoint if the far certificate is
      ordered before the near certificate, and otherwise declaring the
      near identity to be the prevailing endpoint.
Top   ToC   RFC7016 - Page 48
   o  Given a first certificate and a second certificate, test whether a
      new incoming session from the second shall override an existing
      session with the first.  It is RECOMMENDED that the test comprise
      testing whether the certificates are bitwise identical.

   All other semantics for certificates and Endpoint Discriminators are
   determined by the Cryptography Profile and the application.

3.3. Packet Multiplex

An RTMFP typically has one or more interfaces through which it communicates with other RTMFP endpoints. RTMFP can communicate with multiple distinct other RTMFP endpoints through each local interface. Session multiplexing over a shared interface can facilitate peer-to- peer communications through a NAT, by enabling third-party endpoints such as Forwarders (Section 3.5.1.5) and Redirectors (Section 3.5.1.4) to observe the translated public address and inform peers of the translation. An interface is typically a UDP socket (Section 2.2.1) but MAY be any suitable datagram transport service where endpoints can be addressed by IPv4 or IPv6 socket addresses. RTMFP uses a session ID to multiplex and demultiplex communications with distinct endpoints (Section 2.2.2), in addition to the endpoint socket address. This allows an RTMFP to detect a far-end address change (as might happen, for example, in mobile and wireless scenarios) and allows communication sessions to survive address changes. This also allows an RTMFP to act as a Forwarder or Redirector for an endpoint with which it has an active session, by distinguishing startup packets from those of the active session. On receiving a packet, an RTMFP decodes the session ID to look up the corresponding session information context and decryption key. Session ID 0 is reserved for session startup and MUST NOT be used for an active session. A packet for Session ID 0 uses the Default Session Key as defined by the Cryptography Profile.

3.4. Packet Fragmentation

When an RTMFP packet (Section 2.2.4) is unavoidably larger than the path MTU (such as a startup packet containing an RHello (Section 2.3.4) or IIKeying (Section 2.3.7) chunk with a large certificate), it can be fragmented into segments that do not exceed the path MTU by using the Packet Fragment chunk (Section 2.3.1).
Top   ToC   RFC7016 - Page 49
   The packet fragmentation mechanism SHOULD be used only to segment
   unavoidably large packets.  Accordingly, this mechanism SHOULD be
   employed only during session startup with Session ID 0.  This
   mechanism MUST NOT be used instead of the natural fragmentation
   mechanism of the User Data (Section 2.3.11) and Next User Data
   (Section 2.3.12) chunks for dividing the messages of the user's data
   flows into segments that do not exceed the path MTU.

   A fragmented plain RTMFP packet is reassembled by concatenating the
   packetFragment fields of the fragments for the packet in contiguous
   ascending order, starting from index 0 through and including the
   final fragment.

   When reassembling packets for Session ID 0, a receiver SHOULD
   identify the packets by the socket address from which the packet
   containing the fragment was received, as well as the indicated
   packetID.

   A receiver SHOULD allow up to 60 seconds to completely receive a
   fragmented packet for which progress is being made.  A packet is
   progressing if at least one new fragment for it was received in the
   last second.

   A receiver MUST discard a Packet Fragment chunk having an empty
   packetFragment field.

   The mode of each packet containing Packet Fragments for the same
   fragmented packet MUST match the mode of the fragmented packet.  A
   receiver MUST discard any new Packet Fragment chunk received in a
   packet with a mode different from the mode of the packet containing
   the first received fragment.  A receiver MUST discard any reassembled
   packet with a mode different than the packets containing its
   fragments.

   In order to avoid jamming the network, the sender MUST rate limit
   packet transmission.  In the absence of specific path capacity
   information (for instance, during session startup), a sender SHOULD
   NOT send more than 4380 bytes nor more than four packets per distinct
   endpoint every 200 ms.

   To avoid resource exhaustion, a receiver SHOULD limit the number of
   concurrent packet reassembly buffers and the size of each buffer.
   Limits can depend, for example, on the expected size of reassembled
   packets, on the rate at which fragmented packets are expected to be
   received, on the expected degree of interleaving, and on the expected
   function of the receiver.  Limits can depend on the available
   resources of the receiver.  There can be different limits for packets
   with Session ID 0 and packets for established sessions.  For example,
Top   ToC   RFC7016 - Page 50
   a busy server might need to allow for several hundred concurrent
   packet reassembly buffers to accommodate hundreds of connection
   requests per second with potentially interleaved fragments, but a
   client device with constrained resources could allow just a few
   reassembly buffers.  In the absence of specific information regarding
   the expected size of reassembled packets, a receiver should set the
   limit for each packet reassembly buffer to 65536 bytes.

3.5. Sessions

A session is the protocol relationship between a pair of communicating endpoints, comprising the shared and endpoint-specific information context necessary to carry out the communication. The session context at each end includes at least: o TS_RX: the last timestamp received from the far end; o TS_RX_TIME: the time at which TS_RX was first observed to be different than its previous value; o TS_ECHO_TX: the last timestamp echo sent to the far end; o MRTO: the measured retransmission timeout; o ERTO: the effective retransmission timeout; o Cryptographic keys for encrypting and decrypting packets, and for verifying the validity of packets, according to the Cryptography Profile; o Cryptographic near and far nonces according to the Cryptography Profile, where the near nonce is the far end's far nonce, and vice versa; o The certificate of the far end; o The receive session identifier, used by the far end when sending packets to this end; o The send session identifier to use when sending packets to the far end; o DESTADDR: the destination socket address to use when sending packets to the far end; o The set of all sending flow contexts (Section 3.6.2); o The set of all receiving flow contexts (Section 3.6.3);
Top   ToC   RFC7016 - Page 51
   o  The transmission budget, which controls the rate at which data is
      sent into the network (for example, a congestion window);

   o  S_OUTSTANDING_BYTES: the total amount of user message data
      outstanding, or in flight, in the network -- that is, the sum of
      the F_OUTSTANDING_BYTES of each sending flow in the session;

   o  RX_DATA_PACKETS: a count of the number of received packets
      containing at least one User Data chunk since the last
      acknowledgement was sent, initially 0;

   o  ACK_NOW: a boolean flag indicating whether an acknowledgement
      should be sent immediately, initially false;

   o  DELACK_ALARM: an alarm to trigger an acknowledgement after a
      delay, initially unset;

   o  The state, at any time being one of the following values: the
      opening states S_IHELLO_SENT and S_KEYING_SENT, the open state
      S_OPEN, the closing states S_NEARCLOSE and S_FARCLOSE_LINGER, and
      the closed states S_CLOSED and S_OPEN_FAILED; and

   o  The role -- either Initiator or Responder -- of this end of the
      session.
Top   ToC   RFC7016 - Page 52
   Note: The following diagram is only a summary of state transitions
   and their causing events, and is not a complete operational
   specification.

          rcv IIKeying Glare
          far prevails +-------------+   ultimate open timeout
        +--------------|S_IHELLO_SENT|-------------+
        |              +-------------+             |
        |                     |rcv RHello          |
        |                     |                    v
        |                     v             +-------------+
        |<-----------(duplicate session?)   |S_OPEN_FAILED|
        |         yes         |no           +-------------+
        |                     |                    ^
        | rcv IIKeying Glare  v                    |
        | far prevails +-------------+             |
        |<-------------|S_KEYING_SENT|-------------+
        |              +-------------+   ultimate open timeout
        |                     |rcv RIKeying
        |                     |
        |       rcv           v
        |   +-+ IIKeying  +--------+ rcv Close Request
        |   |X|---------->| S_OPEN |--------------------+
        |   +-+           +--------+                    |
        |                   |    |ABRUPT CLOSE          |
        |      ORDERLY CLOSE|    |or rcv Close Ack      |
        |                   |    |or rcv IIKeying       |
        |                   |    |   session override   |
        |                   |    +-------+              |
        |                   v            |              v
        |             +-----------+      |     +-----------------+
        |             |S_NEARCLOSE|      |     |S_FARCLOSE_LINGER|
        |             +-----------+      |     +-----------------+
        |      rcv Close Ack|            |              |rcv Close Ack
        |      or 90 seconds|            v              |or 19 seconds
        |                   |       +--------+          |
        |                   +------>|S_CLOSED|<---------+
        +-------------------------->|        |
                                    +--------+

                      Figure 8: Session State Diagram
Top   ToC   RFC7016 - Page 53

3.5.1. Startup

3.5.1.1. Normal Handshake
RTMFP sessions are established with a 4-way handshake in two round trips. The initiator begins by sending an IHello to one or more candidate addresses for the desired destination endpoint. A responder statelessly sends an RHello in response. The first correct RHello received at the initiator is selected; all others are ignored. The initiator computes its half of the session keying and sends an IIKeying. The responder receives the IIKeying and, if it is acceptable, computes its half of the session keying, at which point it can also compute the shared session keying and session nonces. The responder creates a new S_OPEN session with the initiator and sends an RIKeying. The initiator receives the RIKeying and, if it is acceptable, computes the shared session keying and session nonces. The initiator's session is now S_OPEN. . Initiator Responder . | IHello | |(EPD,Tag) | S_IHELLO_SENT |(SID=0) | |------------------------------->| | | | RHello | | (Tag,Cookie,RCert)| | (SID=0)| |<-------------------------------| S_KEYING_SENT | | | IIKeying | |(ISID,Cookie,ICert,SKIC,ISig) | |(SID=0) | |------------------------------->| | | | RIKeying | | (RSID,SKRC,RSig)| | (SID=ISID,Key=Default)| S_OPEN |<-------------------------------| S_OPEN | | | S E S S I O N | |<-------------------(SID=ISID)--| |--(SID=RSID)------------------->| Figure 9: Normal Handshake In the following sections, the handshake is detailed from the perspectives of the initiator and responder.
Top   ToC   RFC7016 - Page 54
3.5.1.1.1. Initiator
The initiator determines that a session is needed for an Endpoint Discriminator. The initiator creates state for a new opening session and begins with a candidate endpoint address set containing at least one address. The new session is placed in the S_IHELLO_SENT state. If the session does not move to the S_OPEN state before an ultimate open timeout, the session has failed and moves to the S_OPEN_FAILED state. The RECOMMENDED ultimate open timeout is 95 seconds. The initiator chooses a new, unique tag not used by any currently opening session. It is RECOMMENDED that the tag be cryptographically pseudorandom and be at least 8 bytes in length, so that it is hard to guess. The initiator constructs an IHello chunk (Section 2.3.2) with the Endpoint Discriminator and the tag. While the initiator is in the S_IHELLO_SENT state, it sends the IHello to each candidate endpoint address in the set, on a backoff schedule. The backoff SHOULD NOT be less than multiplicative, with not less than 1.5 seconds added to the interval between each attempt. The backoff SHOULD be scheduled separately for each candidate address, since new candidates can be added over time. If the initiator receives a Redirect chunk (Section 2.3.5) with a tag echo matching this session, AND this session is in the S_IHELLO_SENT state, then for each redirect destination indicated in the Redirect: if the candidate endpoint address set contains fewer than REDIRECT_THRESHOLD addresses, add the indicated redirect destination to the candidate endpoint address set. REDIRECT_THRESHOLD SHOULD NOT be more than 24. If the initiator receives an RHello chunk (Section 2.3.4) with a tag echo matching this session, AND this session is in the S_IHELLO_SENT state, AND the responder certificate matches the desired Endpoint Discriminator, AND the certificate is authentic according to the Cryptography Profile, then: 1. If the Canonical Endpoint Discriminator for the responder certificate matches the Canonical Endpoint Discriminator of another existing session in the S_KEYING_SENT or S_OPEN states, AND the certificate of the other opening session matches the desired Endpoint Discriminator, then this session is a duplicate and SHOULD be aborted in favor of the other existing session; otherwise,
Top   ToC   RFC7016 - Page 55
   2.  Move to the S_KEYING_SENT state.  Set DESTADDR, the far-end
       address for the session, to the address from which this RHello
       was received.  The initiator chooses a new, unique receive
       session ID, not used by any other session, for the responder to
       use when sending packets to the initiator.  It computes a Session
       Key Initiator Component appropriate to the responder's
       certificate according to the Cryptography Profile.  Using this
       data and the cookie from the RHello, the initiator constructs and
       signs an IIKeying chunk (Section 2.3.7).

   While the initiator is in the S_KEYING_SENT state, it sends the
   IIKeying to DESTADDR on a backoff schedule.  The backoff SHOULD NOT
   be less than multiplicative, with not less than 1.5 seconds added to
   the interval between each attempt.

   If the initiator receives an RIKeying chunk (Section 2.3.8) in a
   packet with this session's receive session identifier, AND this
   session is in the S_KEYING_SENT state, AND the signature in the chunk
   is authentic according to the far end's certificate (from the
   RHello), AND the Session Key Responder Component successfully
   combines with the Session Key Initiator Component and the near and
   far certificates to form the shared session keys and nonces according
   to the Cryptography Profile, then the session has opened
   successfully.  The session moves to the S_OPEN state.  The send
   session identifier is set from the RIKeying.  Packet encryption,
   decryption, and verification now use the newly computed shared
   session keys, and the session nonces are available for application-
   layer cryptographic challenges.

3.5.1.1.2. Responder
On receipt of an IHello chunk (Section 2.3.2) with an Endpoint Discriminator that selects its identity, an endpoint SHOULD construct an RHello chunk (Section 2.3.4) and send it to the address from which the IHello was received. To avoid a potential resource exhaustion denial of service, the endpoint SHOULD NOT create any persistent state associated with the IHello. The endpoint MUST generate the cookie for the RHello in such a way that it can be recognized as authentic and valid when echoed in an IIKeying. The endpoint SHOULD use the address from which the IHello was received as part of the cookie generation formula. Cookies SHOULD be valid only for a limited time; that lifetime SHOULD NOT be less than 95 seconds (the recommended ultimate session open timeout).
Top   ToC   RFC7016 - Page 56
   On receipt of an FIHello chunk (Section 2.3.3) from a Forwarder
   (Section 3.5.1.5) where the Endpoint Discriminator selects its
   identity, an endpoint SHOULD do one of the following:

   1.  Compute, construct, and send an RHello as though the FIHello was
       an IHello received from the indicated reply address; or

   2.  Construct and send an Implied Redirect (Section 2.3.5) to the
       FIHello's reply address; or

   3.  Ignore this FIHello.

   On receipt of an IIKeying chunk (Section 2.3.7), if the cookie is not
   authentic or if it has expired, ignore this IIKeying; otherwise,

   On receipt of an IIKeying chunk, if the cookie appears authentic but
   does not match the address from which the IIKeying's packet was
   received, perform the special processing at Cookie Change
   (Section 3.5.1.2); otherwise,

   On receipt of an IIKeying with an authentic and valid cookie, if the
   certificate is authentic according to the Cryptography Profile, AND
   the signature in the chunk is authentic according to the far end's
   certificate and the Cryptography Profile, AND the Session Key
   Initiator Component is acceptable, then:

   1.  If the address from which this IIKeying was received corresponds
       to an opening session in the S_IHELLO_SENT or S_KEYING_SENT
       state, perform the special processing at Glare (Section 3.5.1.3);
       otherwise,

   2.  If the address from which this IIKeying was received corresponds
       to a session in the S_OPEN state, then:

       1.  If the receiver was the Responder for the S_OPEN session and
           the session identifier, certificate, and Session Key
           Initiator Component are identical to those of the S_OPEN
           session, this IIKeying is a retransmission, so resend the
           S_OPEN session's RIKeying using the Default Session Key as
           specified below; otherwise,

       2.  If the certificate from this IIKeying does not override the
           certificate of the S_OPEN session, ignore this IIKeying;
           otherwise,
Top   ToC   RFC7016 - Page 57
       3.  The certificate from this IIKeying overrides the certificate
           of the S_OPEN session; this is a new opening session from the
           same identity, and the existing S_OPEN session is stale.
           Move the existing S_OPEN session to S_CLOSED and abort all of
           its flows (signaling exceptions to the user), then continue
           processing this IIKeying.

       Otherwise,

   3.  Compute a Session Key Responder Component and choose a new,
       unique receive session ID not used by any other session for the
       initiator to use when sending packets to the responder.  Using
       this data, construct and, with the Session Key Initiator
       Component, sign an RIKeying chunk (Section 2.3.8).  Using the
       Session Key Initiator and Responder Components and the near and
       far certificates, the responder combines and computes the shared
       session keys and nonces according to the Cryptography Profile.
       The responder creates a new session in the S_OPEN state, with the
       far-endpoint address DESTADDR taken from the source address of
       the packet containing the IIKeying and the send session
       identifier taken from the IIKeying.  The responder sends the
       RIKeying to the initiator using the Default Session Key and the
       requested send session identifier.  Packet encryption,
       decryption, and verification of all future packets for this
       session use the newly computed keys, and the session nonces are
       available for application-layer cryptographic challenges.

3.5.1.2. Cookie Change
In some circumstances, the responder may generate an RHello cookie for an initiator's address that isn't the address the initiator would use when sending packets directly to the responder. This can happen, for example, when the initiator has multiple local addresses and uses one address to reach a Forwarder (Section 3.5.1.5) but another to reach the responder.
Top   ToC   RFC7016 - Page 58
   Consider the following example:

   Initiator                    Forwarder                     Responder
   | IHello                         |                                 |
   |(Src=Ix)                        |                                 |
   |------------------------------->|                                 |
   |                                | FIHello                         |
   |                                |(RA=Ix)                          |
   |                                |-------------------------------->|
   |                                                                  |
   |                                                           RHello |
   |                                                       (Cookie:Ix)|
   |<-----------------------------------------------------------------|
   |                                                                  |
   | IIKeying                                                         |
   |(Cookie:Ix,Src=Iy)                                                |
   |----------------------------------------------------------------->|
   |                                                                  |
   |                                             RHello Cookie Change |
   |                                             (Cookie:Ix,Cookie:Iy)|
   |<-----------------------------------------------------------------|
   |                                                                  |
   | IIKeying                                                         |
   |(Cookie:Iy)                                                       |
   |----------------------------------------------------------------->|
   |                                                                  |
   |                                                         RIKeying |
   |<-----------------------------------------------------------------|
   |                                                                  |
   |<======================== S E S S I O N =========================>|

                  Figure 10: Handshake with Cookie Change

   The initiator has two network interfaces: a first preferred interface
   with address Ix = 192.0.2.100:50000, and a second with address Iy =
   198.51.100.101:50001.  The responder has one interface with address
   Ry = 198.51.100.200:51000, on the same network as the initiator's
   second interface.  The initiator uses its first interface to reach a
   Forwarder.  The Forwarder observes the initiator's address of Ix and
   sends a Forwarded IHello (Section 2.3.3) to the responder.  The
   responder treats this as if it were an IHello from Ix, calculates a
   corresponding cookie, and sends an RHello to Ix.  The initiator
   receives this RHello from Ry and selects that address as the
   destination for the session.  It then sends an IIKeying, copying the
   cookie from the RHello.  However, since the source of the RHello is
   Ry, on a network to which the initiator is directly connected, the
   initiator uses its second interface Iy to send the IIKeying.  The
   responder, on receiving the IIKeying, will compare the cookie to the
Top   ToC   RFC7016 - Page 59
   expected value based on the source address of the packet, and since
   the IIKeying source doesn't match the IHello source used to generate
   the cookie, the responder will reject the IIKeying.

   If the responder determines that it generated the cookie in the
   IIKeying but the cookie doesn't match the sender's address (for
   example, if the cookie is in two parts, with a first part generated
   independently of the initiator's address and a second part dependent
   on the address), the responder SHOULD generate a new cookie based on
   the address from which the IIKeying was received and send an RHello
   Cookie Change chunk (Section 2.3.6) to the source of the IIKeying,
   using the session ID from the IIKeying and the Default Session Key.

   If the initiator receives an RHello Cookie Change chunk for a session
   in the S_KEYING_SENT state, AND the old cookie matches the one
   originally sent to the responder, then the initiator adopts the new
   cookie, constructs and signs a new IIKeying chunk, and sends the new
   IIKeying to the responder.  The initiator SHOULD NOT change the
   cookie for a session more than once.

3.5.1.3. Glare
Glare occurs when two endpoints attempt to initiate sessions to each other concurrently. Glare is detected by receipt of a valid and authentic IIKeying from an endpoint address that is a destination for an opening session. Only one session is allowed between a pair of endpoints. Glare is resolved by comparing the certificate in the received IIKeying with the near end's certificate. The Cryptography Profile defines a certificate comparison function to determine the prevailing endpoint when there is glare. If the near end prevails, discard and ignore the received IIKeying. The far end will abort its opening session on receipt of IIKeying from the near end. Otherwise, the far end prevails: 1. If the certificate in the IIKeying overrides the certificate associated with the near opening session according to the Cryptography Profile, then abort and destroy the near opening session. Then, 2. Continue with normal Responder IIKeying processing (Section 3.5.1.1.2).
Top   ToC   RFC7016 - Page 60
3.5.1.4. Redirector
+-----------+ +------------+ +-----------+ | Initiator |---------->| Redirector | | Responder | | |<----------| | | | | | +------------+ | | | |<=================================>| | +-----------+ +-----------+ Figure 11: Redirector A Redirector acts like a name server for Endpoint Discriminators. An initiator MAY use a Redirector to discover additional candidate endpoint addresses for a desired endpoint. On receipt of an IHello chunk with an Endpoint Discriminator that does not select the Redirector's identity, the Redirector constructs and sends back to the initiator a Responder Redirect chunk (Section 2.3.5) containing one or more additional candidate addresses for the indicated endpoint. Initiator Redirector Responder | IHello | | |------------------------------->| | | | | | Redirect | | |<-------------------------------| | | | | IHello | |----------------------------------------------------------------->| | | | RHello | |<-----------------------------------------------------------------| | | | IIKeying | |----------------------------------------------------------------->| | | | RIKeying | |<-----------------------------------------------------------------| | | |<======================== S E S S I O N =========================>| Figure 12: Handshake Using a Redirector
Top   ToC   RFC7016 - Page 61
   Deployment Design Note: Redirectors SHOULD NOT initiate new sessions
   to endpoints that might use the Redirector's address as a candidate
   for another endpoint, since the far end might interpret the
   Redirector's IIKeying as glare for the far end's initiation to the
   other endpoint.

3.5.1.5. Forwarder
+-----------+ +-----------+ +---+ +-----------+ | Initiator |---->| Forwarder |<===>| N |<===>| Responder | | | +-----------+ | A | | | | |<=====================>| T |<===>| | +-----------+ +---+ +-----------+ Figure 13: Forwarder A responder might be behind a NAT or firewall that doesn't allow inbound packets to reach the endpoint until it first sends an outbound packet for a particular far-endpoint address. A Forwarder's endpoint address MAY be a candidate address for another endpoint. A responder MAY use a Forwarder to receive FIHello chunks sent on behalf of an initiator. On receipt of an IHello chunk with an Endpoint Discriminator that does not select the Forwarder's identity, if the Forwarder has an S_OPEN session with an endpoint whose certificate matches the desired Endpoint Discriminator, the Forwarder constructs and sends an FIHello chunk (Section 2.3.3) to the selected endpoint over the S_OPEN session, using the tag and Endpoint Discriminator from the IHello chunk and the source address of the packet containing the IHello for the corresponding fields of the FIHello.
Top   ToC   RFC7016 - Page 62
   On receipt of an FIHello chunk, a responder might send an RHello or
   Implied Redirect to the original source of the IHello
   (Section 3.5.1.1.2), potentially allowing future packets to flow
   directly between the initiator and responder through the NAT or
   firewall.

   Initiator                    Forwarder           NAT       Responder
   | IHello                         |                |                |
   |------------------------------->|                |                |
   |                                | FIHello        |                |
   |                                |--------------->|--------------->|
   |                                                 |                |
   |                                                 |         RHello |
   |                                                 :<---------------|
   |<------------------------------------------------:                |
   |                                                 :                |
   | IIKeying                                        :                |
   |-------------------------------------------------:--------------->|
   |                                                 :                |
   |                                                 :       RIKeying |
   |                                                 :<---------------|
   |<------------------------------------------------:                |
   |                                                 :                |
   |<======================== S E S S I O N ========>:<==============>|

      Figure 14: Forwarder Handshake where Responder Sends an RHello
Top   ToC   RFC7016 - Page 63
   Initiator                    Forwarder           NAT       Responder
   | IHello                         |                |                |
   |------------------------------->|                |                |
   |                                | FIHello        |                |
   |                                |--------------->|--------------->|
   |                                                 |                |
   |                                                 |       Redirect |
   |                                                 | (Implied,RD={})|
   |                                                 :<---------------|
   |<------------------------------------------------:                |
   |                                                 :                |
   | IHello                                          :                |
   |------------------------------------------------>:--------------->|
   |                                                 :                |
   |                                                 :         RHello |
   |                                                 :<---------------|
   |<------------------------------------------------:                |
   |                                                 :                |
   | IIKeying                                        :                |
   |------------------------------------------------>:--------------->|
   |                                                 :                |
   |                                                 :       RIKeying |
   |                                                 :<---------------|
   |<------------------------------------------------:                |
   |                                                 :                |
   |<======================== S E S S I O N ========>:<==============>|

          Figure 15: Forwarder Handshake where Responder Sends an
                             Implied Redirect

3.5.1.6. Redirector and Forwarder with NAT
+---+ +---+ +---+ +---+ +---+ | I | | N | | I | | N | | R | | n |------>| A |------>| n | | A | | e | | i | | T | | t |<====>| T |<====>| s | | t |<------| |<------| r | | | | p | | i | | | | o | | | | o | | a | | | +---+ | | | n | | t | | | | | | d | | o |<=====>| |<================>| |<====>| e | | r | | | | | | r | +---+ +---+ +---+ +---+ Figure 16: Introduction Service for Initiator and Responder behind NATs
Top   ToC   RFC7016 - Page 64
   An initiator and responder might each be behind distinct NATs or
   firewalls that don't allow inbound packets to reach the respective
   endpoints until each first sends an outbound packet for a particular
   far-endpoint address.

   An introduction service comprising Redirector and Forwarder functions
   may facilitate direct communication between endpoints each behind
   a NAT.

   The responder is registered with the introduction service via an
   S_OPEN session to it.  The service observes and records the
   responder's public NAT address as the DESTADDR of the S_OPEN session.
   The service MAY record other addresses for the responder, for example
   addresses that the responder self-reports as being directly attached.

   The initiator begins with an address of the introduction service as
   an initial candidate.  The Redirector portion of the service sends to
   the initiator a Responder Redirect containing at least the
   responder's public NAT address as previously recorded.  The Forwarder
   portion of the service sends to the responder a Forwarded IHello
   containing the initiator's public NAT address as observed to be the
   source of the IHello.

   The responder sends an RHello to the initiator's public NAT address
   in response to the FIHello.  This will allow inbound packets to the
   responder through its NAT from the initiator's public NAT address.

   The initiator sends an IHello to the responder's public NAT address
   in response to the Responder Redirect.  This will allow inbound
   packets to the initiator through its NAT from the responder's public
   NAT address.

   With transit paths created in both NATs, normal session startup can
   proceed.
Top   ToC   RFC7016 - Page 65
   Initiator     NAT-I    Redirector+Forwarder     NAT-R      Responder
   |               |                |                |                |
   | IHello        |                |                |                |
   |(Dst=Intro)    |                |                |                |
   |-------------->|                |                |                |
   |               |--------------->|                |                |
   |               |                | FIHello        |                |
   |               |                |(RA=NAT-I-Pub)  |                |
   |               |                |--------------->|--------------->|
   |               |       Redirect |                |                |
   |               | (RD={NAT-R-Pub,|                |                |
   |               |           ...})|                |                |
   |<--------------|<---------------|                |                |
   |               |                                 |         RHello |
   |               |                                 | (Dst=NAT-I-Pub)|
   |               |                                 :<---------------|
   |               | (*)  <--------------------------:                |
   | IHello        |                                 :                |
   |(Dst=NAT-R-Pub)|                                 :                |
   |-------------->:                                 :                |
   |               :-------------------------------->:--------------->|
   |               :                                 :                |
   |               :                                 :         RHello |
   |               :                                 :<---------------|
   |<--------------:<--------------------------------:                |
   |               :                                 :                |
   | IIKeying      :                                 :                |
   |-------------->:                                 :                |
   |               :-------------------------------->:--------------->|
   |               :                                 :                |
   |               :                                 :       RIKeying |
   |               :                                 :<---------------|
   |<--------------:<--------------------------------:                |
   |               :                                 :                |
   |<=============>:<======== S E S S I O N ========>:<==============>|

            Figure 17: Handshake with Redirector and Forwarder

   At the point in Figure 17 marked (*), the responder's RHello from the
   FIHello might arrive at the initiator's NAT before or after the
   initiator's IHello is sent outbound to the responder's public NAT
   address.  If it arrives before, it may be dropped by the NAT.  If it
   arrives after, it will transit the NAT and trigger keying without
   waiting for another round-trip time.  The timing of this race
   depends, among other factors, on the relative distances of the
   initiator and responder from each other and from the introduction
   service.
Top   ToC   RFC7016 - Page 66
3.5.1.7. Load Distribution and Fault Tolerance
+---+ IHello/RHello +-------------+ | I |<------------------->| Responder 1 | | n | +-------------+ | i | SESSION +-------------+ | t |<=========>| Responder 2 | | i | +-------------+ | a | IHello... +----------------+ | t |-------------------------> X | Dead Responder | | o | +----------------+ | r | IHello/RHello +-------------+ | |<---------------->| Responder N | +---+ +-------------+ Figure 18: Parallel Open to Multiple Endpoints As specified in Section 3.2, more than one endpoint is allowed to be selected by one Endpoint Discriminator. This will typically be the case for a set of servers, any of which could accommodate a connecting client. As specified in Section 3.5.1.1.1, an initiator is allowed to use multiple candidate endpoint addresses when starting a session, and the sender of the first acceptable RHello chunk to be received is selected to complete the session, with later responses ignored. An initiator can start with the multiple candidate endpoint addresses, or it may learn them during startup from one or more Redirectors (Section 3.5.1.4). Parallel open to multiple endpoints for the same Endpoint Discriminator, combined with selection by earliest RHello, can be used for load distribution and fault tolerance. The cost at each endpoint that is not selected is limited to receiving and processing an IHello, and generating and sending an RHello. In one circumstance, multiple servers of similar processing and networking capacity may be located in near proximity to each other, such as in a data center. In this circumstance, a less heavily loaded server can respond to an IHello more quickly than more heavily loaded servers and will tend to be selected by a client. In another circumstance, multiple servers may be located in different physical locations, such as different data centers. In this circumstance, a server that is located nearer (in terms of network distance) to the client can respond earlier than more distant servers and will tend to be selected by the client.
Top   ToC   RFC7016 - Page 67
   Multiple servers, in proximity or distant from one another, can form
   a redundant pool of servers.  A client can perform a parallel open to
   the multiple servers.  In normal operation, the multiple servers will
   all respond, and the client will select one of them as described
   above.  If one of the multiple servers fails, other servers in the
   pool can still respond to the client, allowing the client to succeed
   to an S_OPEN session with one of them.

3.5.2. Congestion Control

An RTMFP MUST implement congestion control and avoidance algorithms that are "TCP compatible", in accordance with Internet best current practice [RFC2914]. The algorithms SHOULD NOT be more aggressive in sending data than those described in "TCP Congestion Control" [RFC5681] and MUST NOT be more aggressive in sending data than the "slow start algorithm" described in Section 3.1 of RFC 5681. An endpoint maintains a transmission budget in the session information context of each S_OPEN session (Section 3.5), controlling the rate at which the endpoint sends data into the network. For window-based congestion control and avoidance algorithms, the transmission budget is the congestion window, which is the amount of user data that is allowed to be outstanding, or in flight, in the network. Transmission is allowed when S_OUTSTANDING_BYTES (Section 3.5) is less than the congestion window (Section 3.6.2.3). See Appendix A for an experimental window-based congestion control algorithm for real-time and bulk data. An endpoint avoids sending large bursts of data or packets into the network (Section 3.5.2.3). A sending endpoint increases and decreases its transmission budget in response to acknowledgements (Section 3.6.2.4) and loss according to the congestion control and avoidance algorithms. Loss is detected by negative acknowledgement (Section 3.6.2.5) and timeout (Section 3.6.2.6). Timeout is determined by the Effective Retransmission Timeout (ERTO) (Section 3.5.2.2). The ERTO is measured using the Timestamp and Timestamp Echo packet header fields (Section 2.2.4). A receiving endpoint acknowledges all received data (Section 3.6.3.4) to enable the sender to measure receipt of data, or lack thereof. A receiving endpoint may be receiving time critical (or real-time) data from a first sender while receiving data from other senders. The receiving endpoint can signal its other senders (Section 2.2.4)
Top   ToC   RFC7016 - Page 68
   to cause them to decrease the aggressiveness of their congestion
   control and avoidance algorithms, in order to yield network capacity
   to the time critical data (Section 3.5.2.1).

3.5.2.1. Time Critical Reverse Notification
A sender can increase its transmission budget at a rate compatible with (but not exceeding) the "slow start algorithm" specified in RFC 5681 (with which the transmission rate is doubled every round trip when beginning or restarting transmission, until loss is detected). However, a sender MUST behave as though the slow start threshold SSTHRESH is clamped to 0 (disabling the slow start algorithm's exponential increase behavior) on a session where a Time Critical Reverse Notification (Section 2.2.4) indication has been received from the far end within the last 800 milliseconds, unless the sender is itself currently sending time critical data to the far end. During each round trip, a sender SHOULD NOT increase the transmission budget by more than 0.5% or by 384 bytes per round trip (whichever is greater) on a session where a Time Critical Reverse Notification indication has been received from the far end within the last 800 milliseconds, unless the sender is itself currently sending time critical data to the far end.
3.5.2.2. Retransmission Timeout
RTMFP uses the ERTO to detect when a user data fragment has been lost in the network. The ERTO is typically calculated in a manner similar to that specified in "Requirements for Internet Hosts - Communication Layers" [RFC1122] and is a function of round-trip time measurements and persistent timeout behavior. The ERTO SHOULD be at least 250 milliseconds and SHOULD allow for the receiver to delay sending an acknowledgement for up to 200 milliseconds (Section 3.6.3.4.4). The ERTO MUST NOT be less than the round-trip time. To facilitate round-trip time measurement, an endpoint MUST implement the Timestamp Echo facility: o On a session entering the S_OPEN state, initialize TS_RX_TIME to negative infinity, and initialize TS_RX and TS_ECHO_TX to have no value.
Top   ToC   RFC7016 - Page 69
   o  On receipt of a packet in an S_OPEN session with the
      timestampPresent (Section 2.2.4) flag set, if the timestamp field
      in the packet is different than TS_RX, set TS_RX to the value of
      the timestamp field in the packet, and set TS_RX_TIME to the
      current time.

   o  When sending a packet to the far end in an S_OPEN session:

      1.  Calculate TS_RX_ELAPSED = current time - TS_RX_TIME.  If
          TS_RX_ELAPSED is more than 128 seconds, then set TS_RX and
          TS_ECHO_TX to have no value, and do not include a timestamp
          echo; otherwise,

      2.  Calculate TS_RX_ELAPSED_TICKS to be the number of whole
          4-millisecond periods in TS_RX_ELAPSED; then

      3.  Calculate TS_ECHO = (TS_RX + TS_RX_ELAPSED_TICKS) MODULO
          65536; then

      4.  If TS_ECHO is not equal to TS_ECHO_TX, then set TS_ECHO_TX to
          TS_ECHO, set the timestampEchoPresent flag, and set the
          timestampEcho field to TS_ECHO_TX.

   The remainder of this section describes an OPTIONAL method for
   calculating the ERTO.  Real-time applications and P2P mesh
   applications often require knowing the round-trip time and RTT
   variance.  This section additionally describes a method for measuring
   the round-trip time and RTT variance, and calculating a smoothed
   round-trip time.

   Let the session information context contain additional variables:

   o  TS_TX: the last timestamp sent to the far end, initialized to have
      no value;

   o  TS_ECHO_RX: the last timestamp echo received from the far end,
      initialized to have no value;

   o  SRTT: the smoothed round-trip time, initialized to have no value;

   o  RTTVAR: the round-trip time variance, initialized to 0.

   Initialize MRTO to 250 milliseconds.

   Initialize ERTO to 3 seconds.
Top   ToC   RFC7016 - Page 70
   On sending a packet to the far end of an S_OPEN session, if the
   current send timestamp is not equal to TS_TX, then set TS_TX to the
   current send timestamp, set the timestampPresent flag in the packet
   header, and set the timestamp field to TS_TX.

   On receipt of a packet from the far end of an S_OPEN session, if the
   timestampEchoPresent flag is set in the packet header, AND the
   timestampEcho field is not equal to TS_ECHO_RX, then:

   1.  Set TS_ECHO_RX to timestampEcho;

   2.  Calculate RTT_TICKS = (current send timestamp - timestampEcho)
       MODULO 65536;

   3.  If RTT_TICKS is greater than 32767, the measurement is invalid,
       so discard this measurement; otherwise,

   4.  Calculate RTT = RTT_TICKS * 4 milliseconds;

   5.  If SRTT has a value, then calculate new values of RTTVAR
       and SRTT:

       1.  RTT_DELTA = | SRTT - RTT |;

       2.  RTTVAR = ((3 * RTTVAR) + RTT_DELTA) / 4;

       3.  SRTT = ((7 * SRTT) + RTT) / 8.

   6.  If SRTT has no value, then set SRTT = RTT and RTTVAR = RTT / 2;

   7.  Set MRTO = SRTT + 4 * RTTVAR + 200 milliseconds;

   8.  Set ERTO to MRTO or 250 milliseconds, whichever is greater.

   A retransmission timeout occurs when the most recently transmitted
   user data fragment has remained outstanding in the network for ERTO.
   When this timeout occurs, increase ERTO on an exponential backoff
   with an ultimate backoff cap of 10 seconds:

   1.  Calculate ERTO_BACKOFF = ERTO * 1.4142;

   2.  Calculate ERTO_CAPPED to be ERTO_BACKOFF or 10 seconds, whichever
       is less;

   3.  Set ERTO to ERTO_CAPPED or MRTO, whichever is greater.
Top   ToC   RFC7016 - Page 71
3.5.2.3. Burst Avoidance
An application's sending patterns may cause the transmission budget to grow to a large value, but at times its sending patterns will result in a comparatively small amount of data outstanding in the network. In this circumstance, especially with a window-based congestion avoidance algorithm, if the application then has a large amount of new data to send (for example, a new bulk data transfer), it could send data into the network all at once to fill the window. This kind of transmission burst is undesirable, however, because it can jam interfaces, links, and buffers. Accordingly, in any session, an endpoint SHOULD NOT send more than six packets containing user data between receiving any acknowledgements or retransmission timeouts. The following describes an OPTIONAL method to avoid bursting large numbers of packets into the network: Let the session information context contain an additional variable DATA_PACKET_COUNT, initialized to 0. Transmission of a user data fragment on this session is not allowed if DATA_PACKET_COUNT is greater than or equal to 6, regardless of any other allowance of the congestion control algorithm. On transmission of a packet containing at least one User Data chunk (Section 2.3.11), set DATA_PACKET_COUNT = DATA_PACKET_COUNT + 1. On receipt of an acknowledgement chunk (Sections 2.3.13 and 2.3.14), set DATA_PACKET_COUNT to 0. On a retransmission timeout, set DATA_PACKET_COUNT to 0.

3.5.3. Address Mobility

Sessions are demultiplexed with a 32-bit session ID, rather than by endpoint address. This allows an endpoint's address to change during an S_OPEN session. This can happen, for example, when switching from a wireless to a wired network, or when moving from one wireless base station to another, or when a NAT restarts. If the near end receives a valid packet for an S_OPEN session from a source address that doesn't match DESTADDR, the far end might have changed addresses. The near end SHOULD verify that the far end is definitively at the new address before changing DESTADDR. A suggested verification method is described in Section 3.5.4.2.
Top   ToC   RFC7016 - Page 72

3.5.4. Ping

If an endpoint receives a Ping chunk (Section 2.3.9) in a session in the S_OPEN state, it SHOULD construct and send a Ping Reply chunk (Section 2.3.10) in response if possible, copying the message unaltered. The Ping Reply SHOULD be sent as quickly as possible following receipt of a Ping. The semantics of a Ping's message is reserved for the sender; a receiver SHOULD NOT interpret the Ping's message. Endpoints can use the mechanism of the Ping chunk and the expected Ping Reply for any purpose. This specification doesn't mandate any specific constraints on the format or semantics of a Ping message. A Ping Reply MUST be sent only as a response to a Ping. Receipt of a Ping Reply implies live bidirectional connectivity. This specification doesn't mandate any other semantics for a Ping Reply.
3.5.4.1. Keepalive
An endpoint can use a Ping to test for live bidirectional connectivity, to test that the far end of a session is still in the S_OPEN state, to keep NAT translations alive, and to keep firewall holes open. An endpoint can use a Ping to hasten detection of a near-end address change by the far end. An endpoint may declare a session to be defunct and dead after a persistent failure by the far end to return Ping Replies in response to Pings. If used for these purposes, a Keepalive Ping SHOULD have an empty message. A Keepalive Ping SHOULD NOT be sent more often than once per ERTO. If a corresponding Ping Reply is not received within ERTO of sending the Ping, ERTO SHOULD be increased according to Section 3.5.2 ("Congestion Control").
Top   ToC   RFC7016 - Page 73
3.5.4.2. Address Mobility
This section describes an OPTIONAL but suggested method for processing and verifying a far-end address change. Let the session context contain additional variables MOB_TX_TS, MOB_RX_TS, and MOB_SECRET. MOB_TX_TS and MOB_RX_TS have initial values of negative infinity. MOB_SECRET should be a cryptographically pseudorandom value not less than 128 bits in length and known only to this end. On receipt of a packet for an S_OPEN session, after processing all chunks in the packet: if the session is still in the S_OPEN state, AND the source address of the packet does not match DESTADDR, AND MOB_TX_TS is at least one second in the past, then: 1. Set MOB_TX_TS to the current time; 2. Construct a Ping message comprising the following: a marking to indicate (to this end when returned in a Ping Reply) that it is a mobility check (for example, the first byte being ASCII 'M' for "Mobility"), a timestamp set to MOB_TX_TS, and a cryptographic hash over the following: the preceding items, the address from which the packet was received, and MOB_SECRET; and 3. Send this Ping to the address from which the packet was received, instead of DESTADDR. On receipt of a Ping Reply in an S_OPEN session, if the Ping Reply's message satisfies all of these conditions: o it has this end's expected marking to indicate that it is a mobility check, and o the timestamp in the message is not more than 120 seconds in the past, and o the timestamp in the message is greater than MOB_RX_TS, and o the cryptographic hash matches the expected value according to the contents of the message plus the source address of the packet containing this Ping Reply and MOB_SECRET,
Top   ToC   RFC7016 - Page 74
   then:

   1.  Set MOB_RX_TS to the timestamp in the message; and

   2.  Set DESTADDR to the source address of the packet containing this
       Ping Reply.

3.5.4.3. Path MTU Discovery
"Packetization Layer Path MTU Discovery" [RFC4821] describes a method for measuring the path MTU between communicating endpoints. An RTMFP SHOULD perform path MTU discovery. The method described in RFC 4821 can be adapted for use in RTMFP by sending a probe packet comprising one of the Padding chunk types (type 0x00 or 0xff) and a Ping. The Ping chunk SHOULD come after the Padding chunk, to guard against a false positive response in case the probe packet is truncated.

3.5.5. Close

An endpoint may close a session at any time. Typically, an endpoint will close a session when there have been no open flows in either direction for a time. In another circumstance, an endpoint may be ceasing operation and will close all of its sessions even if they have open flows. To close an S_OPEN session in a reliable and orderly fashion, an endpoint moves the session to the S_NEARCLOSE state. On a session transitioning from S_OPEN to S_NEARCLOSE and every 5 seconds thereafter while still in the S_NEARCLOSE state, send a Session Close Request chunk (Section 2.3.17). A session that has been in the S_NEARCLOSE state for at least 90 seconds (allowing time to retransmit the Session Close Request multiple times) SHOULD move to the S_CLOSED state. On a session transitioning from S_OPEN to the S_NEARCLOSE, S_FARCLOSE_LINGER or S_CLOSED state, immediately abort and terminate all open or closing flows. Flows only exist in S_OPEN sessions. To close an S_OPEN session abruptly, send a Session Close Acknowledgement chunk (Section 2.3.18), then move to the S_CLOSED state.
Top   ToC   RFC7016 - Page 75
   On receipt of a Session Close Request chunk for a session in the
   S_OPEN, S_NEARCLOSE, or S_FARCLOSE_LINGER states, send a Session
   Close Acknowledgement chunk; then, if the session is in the S_OPEN
   state, move to the S_FARCLOSE_LINGER state.

   A session that has been in the S_FARCLOSE_LINGER state for at least
   19 seconds (allowing time to answer 3 retransmissions of a Session
   Close Request) SHOULD move to the S_CLOSED state.

   On receipt of a Session Close Acknowledgement chunk for a session in
   the S_OPEN, S_NEARCLOSE, or S_FARCLOSE_LINGER states, move to the
   S_CLOSED state.



(page 75 continued on part 4)

Next Section