Skip to main content

Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)
RFC 5713

Document Type RFC - Informational (January 2010)
Authors Stefaan De Cnodder , Hannes Tschofenig , Hassnaa Moustafa
Last updated 2018-12-20
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
IESG Responsible AD Ralph Droms
Send notices to (None)
RFC 5713
Internet Engineering Task Force (IETF)                       H. Moustafa
Request for Comments: 5713                                France Telecom
Category: Informational                                    H. Tschofenig
ISSN: 2070-1721                                   Nokia Siemens Networks
                                                           S. De Cnodder
                                                          Alcatel-Lucent
                                                            January 2010

           Security Threats and Security Requirements for the
                  Access Node Control Protocol (ANCP)

Abstract

   The Access Node Control Protocol (ANCP) aims to communicate Quality
   of Service (QoS)-related, service-related, and subscriber-related
   configurations and operations between a Network Access Server (NAS)
   and an Access Node (e.g., a Digital Subscriber Line Access
   Multiplexer (DSLAM)).  The main goal of this protocol is to allow the
   NAS to configure, manage, and control access equipment, including the
   ability for the Access Nodes to report information to the NAS.

   This present document investigates security threats that all ANCP
   nodes could encounter.  This document develops a threat model for
   ANCP security, with the aim of deciding which security functions are
   required.  Based on this, security requirements regarding the Access
   Node Control Protocol are defined.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc5713.

Moustafa, et al.             Informational                      [Page 1]
RFC 5713                      ANCP Threats                  January 2010

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction ....................................................3
   2. Specification Requirements ......................................3
   3. System Overview and Threat Model ................................4
   4. Objectives of Attackers .........................................7
   5. Potential Attacks ...............................................7
      5.1. Denial of Service (DoS) ....................................7
      5.2. Integrity Violation ........................................8
      5.3. Downgrading ................................................8
      5.4. Traffic Analysis ...........................................8
      5.5. Management Attacks .........................................8
   6. Attack Forms ....................................................9
   7. Attacks against ANCP ...........................................10
      7.1. Dynamic Access-Loop Attributes ............................11
      7.2. Access-Loop Configuration .................................12
      7.3. Remote Connectivity Test ..................................14
      7.4. Multicast .................................................14
   8. Security Requirements ..........................................16
   9. Security Considerations ........................................16
   10. Acknowledgments ...............................................17
   11. References ....................................................17
      11.1. Normative References .....................................17
      11.2. Informative References ...................................17

Moustafa, et al.             Informational                      [Page 2]
RFC 5713                      ANCP Threats                  January 2010

1.  Introduction

   The Access Node Control Protocol (ANCP) aims to communicate QoS-
   related, service-related, and subscriber-related configurations and
   operations between a Network Access Server (NAS) and an Access Node
   (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)).

   [ANCP-FRAME] illustrates the framework, usage scenarios, and general
   requirements for ANCP.  This document focuses on describing security
   threats and deriving security requirements for the Access Node
   Control Protocol, considering the ANCP use cases defined in
   [ANCP-FRAME] as well as the guidelines for IETF protocols' security
   requirements given in [RFC3365].  Section 5 and Section 6,
   respectively, describe the potential attacks and the different attack
   forms that are liable to take place within ANCP, while Section 7
   applies the described potential attacks to ANCP and its different use
   cases.  Security policy negotiation, including authentication and
   authorization to define the per-subscriber policy at the policy/AAA
   (Authentication, Authorization, and Accounting) server, is out of the
   scope of this work.  As a high-level summary, the following aspects
   need to be considered:

   Message Protection:

      Signaling message content can be protected against eavesdropping,
      modification, injection, and replay while in transit.  This
      applies to both ANCP headers and payloads.

   Prevention against Impersonation:

      It is important that protection be available against a device
      impersonating an ANCP node (i.e., an unauthorized device
      generating an ANCP message and pretending it was generated by a
      valid ANCP node).

   Prevention of Denial-of-Service Attacks:

      ANCP nodes and the network have finite resources (state storage,
      processing power, bandwidth).  It is important to protect against
      exhaustion attacks on these resources and to prevent ANCP nodes
      from being used to launch attacks on other network elements.

2.  Specification Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119], with the

Moustafa, et al.             Informational                      [Page 3]
RFC 5713                      ANCP Threats                  January 2010

   qualification that, unless otherwise stated, they apply to the design
   of the Access Node Control Protocol (ANCP), not its implementation or
   application.

   The relevant components are described in Section 3.

3.  System Overview and Threat Model

   As described in [ANCP-FRAME] and schematically shown in Figure 1, the
   Access Node Control system consists of the following components:

   Network Access Server (NAS):

      A NAS provides access to a service (e.g., network access) and
      operates as a client of the AAA protocol.  The AAA client is
      responsible for passing authentication information to designated
      AAA servers and then acting on the response that is returned.

   Authentication, Authorization, and Accounting (AAA) server:

      A AAA server is responsible for authenticating users, authorizing
      access to services, and returning authorization information
      (including configuration parameters) back to the AAA client to
      deliver service to the user.  As a consequence, service usage
      accounting might be enabled and information about the user's
      resource usage will be sent to the AAA server.

   Access Node (AN):

      The AN is a network device, usually located at a service provider
      central office or street cabinet, that terminates access-loop
      connections from subscribers.  In case the access loop is a
      Digital Subscriber Line (DSL), this is often referred to as a DSL
      Access Multiplexer (DSLAM).

   Customer Premises Equipment (CPE):

      A CPE is a device located inside a subscriber's premise that is
      connected at the LAN side of the Home Gateway (HGW).

   Home Gateway (HGW):

      The HGW connects the different Customer Premises Equipments (CPEs)
      to the Access Node and the access network.  In case of DSL, the
      HGW is a DSL Network Termination (NT) that could either operate as
      a layer 2 bridge or as a layer 3 router.  In the latter case, such
      a device is also referred to as a Routing Gateway (RG).

Moustafa, et al.             Informational                      [Page 4]
RFC 5713                      ANCP Threats                  January 2010

   Aggregation Network:

      The aggregation network provides traffic aggregation from multiple
      ANs towards the NAS.  ATM or Ethernet transport technologies can
      be used.

   For the threat analysis, this document focuses on the ANCP
   communication between the Access Node and the NAS.  However,
   communications with the other components (such as HGW, CPE, and the
   AAA server) play a role in the understanding of the system
   architecture and of what triggers ANCP communications.  Note that the
   NAS and the AN might belong to two different administrative realms.
   The threat model and the security requirements in this document
   consider this latter case.

                                                             +--------+
                                                             | AAA    |
                                                             | Server |
                                                             +--------+
                                                                  |
                                                                  |
      +---+   +---+   +------+    +-----------+    +-----+   +--------+
      |CPE|---|HGW|---|      |    |Aggregation|    |     |   |        |
      +---+   +---+   |Access|    | Network   |    |     |   |Internet|
                      | Node |----|           |----| NAS |---|   /    |
      +---+   +---+   | (AN) |    |           |    |     |   |Regional|
      |CPE|---|HGW|---|      |    |           |    |     |   |Network |
      +---+   +---+   +------+    +-----------+    +-----+   +--------+

                         Figure 1: System Overview

   In the absence of an attack, the NAS receives configuration
   information from the AAA server related to a CPE attempting to access
   the network.  A number of parameters, including Quality of Service
   information, need to be conveyed to the Access Node in order to
   become effective.  The Access Node Control Protocol is executed
   between the NAS and the AN to initiate control requests.  The AN
   returns responses to these control requests and provides information
   reports.

   For this to happen, the following individual steps must occur:

   o  The AN discovers the NAS.

   o  The AN needs to start the protocol communication with the NAS to
      announce its presence.

Moustafa, et al.             Informational                      [Page 5]
RFC 5713                      ANCP Threats                  January 2010

   o  The AN and the NAS perform a capability exchange.

   o  The NAS sends requests to the AN.

   o  The AN processes these requests, authorizes the actions, and
      responds with the appropriate answer.  In order to fulfill the
      commands, it might be necessary for the AN to communicate with the
      HGW or other nodes, for example, as part of a keep-alive
      mechanism.

   o  The AN provides status reports to the NAS.

   Attackers can be:

   o  off-path, i.e., they cannot see the messages exchanged between the
      AN and the NAS;

   o  on-path, i.e., they can see the messages exchanged between the AN
      and the NAS.

   Both off-path and on-path attackers can be:

   o  passive, i.e., they do not participate in the network operation
      but rather listen to all transfers to obtain the maximum possible
      information;

   o  active, i.e., they participate in the network operation and can
      inject falsified packets.

   We assume the following threat model:

   o  An off-path adversary located at the CPE or the HGW.

   o  An off-path adversary located on the Internet or a regional
      network that connects one or more NASes and associated access
      networks to Network Service Providers (NSPs) and Application
      Service Providers (ASPs).

   o  An on-path adversary located at network elements between the AN
      and the NAS.

   o  An on-path adversary taking control over the NAS.

   o  An on-path adversary taking control over the AN.

Moustafa, et al.             Informational                      [Page 6]
RFC 5713                      ANCP Threats                  January 2010

4.  Objectives of Attackers

   Attackers may direct their efforts either against an individual
   entity or against a large portion of the access network.  Attacks
   fall into three classes:

   o  Attacks to disrupt the communication for individual customers.

   o  Attacks to disrupt the communication of a large fraction of
      customers in an access network.  These also include attacks to the
      network itself or a portion of it, such as attacks to disrupt the
      network services or attacks to destruct the network functioning.

   o  Attacks to gain profit for the attacker through modifying the QoS
      settings.  Also, through replaying old packets (of another
      privileged client, for instance), an attacker can attempt to
      configure a better QoS profile on its own DSL line, increasing its
      own benefit.

5.  Potential Attacks

   This section discusses the different types of attacks against ANCP,
   while Section 6 describes the possible means of their occurrence.

   ANCP is mainly susceptible to the following types of attacks:

5.1.  Denial of Service (DoS)

   A number of denial-of-service (DoS) attacks can cause ANCP nodes to
   malfunction.  When state is established or certain functions are
   performed without requiring prior authorization, there is a chance to
   mount denial-of-service attacks.  An adversary can utilize this fact
   to transmit a large number of signaling messages to allocate state at
   nodes and to cause consumption of resources.  Also, an adversary,
   through DoS, can prevent certain subscribers from accessing certain
   services.  Moreover, DoS can take place at the AN or the NAS
   themselves, where it is possible for the NAS (or the AN) to
   intentionally ignore the requests received from the AN (or the NAS)
   through not replying to them.  This causes the sender of the request
   to retransmit the request, which might allocate additional state at
   the sender side to process the reply.  Allocating more state may
   result in memory depletion.

Moustafa, et al.             Informational                      [Page 7]
RFC 5713                      ANCP Threats                  January 2010

5.2.  Integrity Violation

   Adversaries gaining illegitimate access on the transferred messages
   can act on these messages, causing integrity violation.  Integrity
   violation can cause unexpected network behavior, leading to a
   disturbance in the network services as well as in the network
   functioning.

5.3.  Downgrading

   Protocols may be useful in a variety of scenarios with different
   security and functional requirements.  Different parts of a network
   (e.g., within a building, across a public carrier's network, or over
   a private microwave link) may need different levels of protection.
   It is often difficult to meet these (sometimes conflicting)
   requirements with a single mechanism or fixed set of parameters;
   thus, often a selection of mechanisms and parameters is offered.  A
   protocol is required to agree on certain (security) mechanisms and
   parameters.  An insecure parameter exchange or security negotiation
   protocol can give an adversary the opportunity to mount a downgrading
   attack to force selection of mechanisms weaker than those mutually
   desired.  Thus, without binding the negotiation process to the
   legitimate parties and protecting it, ANCP might only be as secure as
   the weakest mechanism provided (e.g., weak authentication) and the
   benefits of defining configuration parameters and a negotiation
   protocol are lost.

5.4.  Traffic Analysis

   An adversary can be placed at the NAS, the AN, or any other network
   element capturing all traversing packets.  Adversaries can thus have
   unauthorized information access.  As well, they can gather
   information relevant to the network and then use this information in
   gaining later unauthorized access.  This attack can also help
   adversaries in other malicious purposes -- for example, capturing
   messages sent from the AN to the NAS announcing that a DSL line is up
   and containing some information related to the connected client.
   This could be any form of information about the client and could also
   be an indicator of whether or not the DSL subscriber is at home at a
   particular moment.

5.5.  Management Attacks

   Since the ANCP sessions are configured in the AN and not in the NAS
   [ANCP-FRAME], most configurations of ANCP are done in the AN.
   Consequently, the management attacks to ANCP mainly concern the AN
   configuration phase.  In this context, the AN MIB module could create
   disclosure- and misconfiguration-related attacks.  [ANCP-MIB] defines

Moustafa, et al.             Informational                      [Page 8]
RFC 5713                      ANCP Threats                  January 2010

   quot;error: connection illegal for this process".

         Otherwise return "error: connection does not exist".

      LISTEN STATE

         Return "state = LISTEN", and the TCB pointer.

      SYN-SENT STATE

         Return "state = SYN-SENT", and the TCB pointer.

      SYN-RECEIVED STATE

         Return "state = SYN-RECEIVED", and the TCB pointer.

      ESTABLISHED STATE

         Return "state = ESTABLISHED", and the TCB pointer.

      FIN-WAIT-1 STATE

         Return "state = FIN-WAIT-1", and the TCB pointer.

      FIN-WAIT-2 STATE

         Return "state = FIN-WAIT-2", and the TCB pointer.

      CLOSE-WAIT STATE

         Return "state = CLOSE-WAIT", and the TCB pointer.

      CLOSING STATE

         Return "state = CLOSING", and the TCB pointer.

      LAST-ACK STATE

         Return "state = LAST-ACK", and the TCB pointer.

      TIME-WAIT STATE

         Return "state = TIME-WAIT", and the TCB pointer.

Eddy                      Expires May 16, 2018                 [Page 65]
Internet-Draft              TCP Specification              November 2017

   SEGMENT ARRIVES

      If the state is CLOSED (i.e., TCB does not exist) then

         all data in the incoming segment is discarded.  An incoming
         segment containing a RST is discarded.  An incoming segment not
         containing a RST causes a RST to be sent in response.  The
         acknowledgment and sequence field values are selected to make
         the reset sequence acceptable to the TCP that sent the
         offending segment.

         If the ACK bit is off, sequence number zero is used,

            <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>

         If the ACK bit is on,

            <SEQ=SEG.ACK><CTL=RST>

         Return.

      If the state is LISTEN then

         first check for an RST

            An incoming RST should be ignored.  Return.

         second check for an ACK

            Any acknowledgment is bad if it arrives on a connection
            still in the LISTEN state.  An acceptable reset segment
            should be formed for any arriving ACK-bearing segment.  The
            RST should be formatted as follows:

               <SEQ=SEG.ACK><CTL=RST>

            Return.

         third check for a SYN

            If the SYN bit is set, check the security.  If the security/
            compartment on the incoming segment does not exactly match
            the security/compartment in the TCB then send a reset and
            return.

               <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>

Eddy                      Expires May 16, 2018                 [Page 66]
Internet-Draft              TCP Specification              November 2017

            If the SEG.PRC is greater than the TCB.PRC then if allowed
            by the user and the system set TCB.PRC<-SEG.PRC, if not
            allowed send a reset and return.

               <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>

            If the SEG.PRC is less than the TCB.PRC then continue.

            Set RCV.NXT to SEG.SEQ+1, IRS is set to SEG.SEQ and any
            other control or text should be queued for processing later.
            ISS should be selected and a SYN segment sent of the form:

               <SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>

            SND.NXT is set to ISS+1 and SND.UNA to ISS.  The connection
            state should be changed to SYN-RECEIVED.  Note that any
            other incoming control or data (combined with SYN) will be
            processed in the SYN-RECEIVED state, but processing of SYN
            and ACK should not be repeated.  If the listen was not fully
            specified (i.e., the foreign socket was not fully
            specified), then the unspecified fields should be filled in
            now.

         fourth other text or control

            Any other control or text-bearing segment (not containing
            SYN) must have an ACK and thus would be discarded by the ACK
            processing.  An incoming RST segment could not be valid,
            since it could not have been sent in response to anything
            sent by this incarnation of the connection.  So you are
            unlikely to get here, but if you do, drop the segment, and
            return.

      If the state is SYN-SENT then

         first check the ACK bit

            If the ACK bit is set

               If SEG.ACK =< ISS, or SEG.ACK > SND.NXT, send a reset
               (unless the RST bit is set, if so drop the segment and
               return)

                  <SEQ=SEG.ACK><CTL=RST>

               and discard the segment.  Return.

Eddy                      Expires May 16, 2018                 [Page 67]
Internet-Draft              TCP Specification              November 2017

               If SND.UNA < SEG.ACK =< SND.NXT then the ACK is
               acceptable.  (TODO: in processing Errata ID 3300, it was
               noted that some stacks in the wild that do not send data
               on the SYN are just checking that SEG.ACK == SND.NXT ...
               think about whether anything should be said about that
               here)

         second check the RST bit

            If the RST bit is set

               A potential blind reset attack is described in RFC 5961
               [24], with the mitigation that a TCP implementation
               SHOULD first check that the sequence number exactly
               matches RCV.NXT prior to executing the action in the next
               paragraph.

               If the ACK was acceptable then signal the user "error:
               connection reset", drop the segment, enter CLOSED state,
               delete TCB, and return.  Otherwise (no ACK) drop the
               segment and return.

         third check the security and precedence

            If the security/compartment in the segment does not exactly
            match the security/compartment in the TCB, send a reset

               If there is an ACK

                  <SEQ=SEG.ACK><CTL=RST>

               Otherwise

                  <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>

            If there is an ACK

               The precedence in the segment must match the precedence
               in the TCB, if not, send a reset

                  <SEQ=SEG.ACK><CTL=RST>

            If there is no ACK

               If the precedence in the segment is higher than the
               precedence in the TCB then if allowed by the user and the
               system raise the precedence in the TCB to that in the

Eddy                      Expires May 16, 2018                 [Page 68]
Internet-Draft              TCP Specification              November 2017

               segment, if not allowed to raise the prec then send a
               reset.

                  <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>

               If the precedence in the segment is lower than the
               precedence in the TCB continue.

            If a reset was sent, discard the segment and return.

         fourth check the SYN bit

            This step should be reached only if the ACK is ok, or there
            is no ACK, and it the segment did not contain a RST.

            If the SYN bit is on and the security/compartment and
            precedence are acceptable then, RCV.NXT is set to SEG.SEQ+1,
            IRS is set to SEG.SEQ.  SND.UNA should be advanced to equal
            SEG.ACK (if there is an ACK), and any segments on the
            retransmission queue which are thereby acknowledged should
            be removed.

            If SND.UNA > ISS (our SYN has been ACKed), change the
            connection state to ESTABLISHED, form an ACK segment

               <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

            and send it.  Data or controls which were queued for
            transmission may be included.  If there are other controls
            or text in the segment then continue processing at the sixth
            step below where the URG bit is checked, otherwise return.

            Otherwise enter SYN-RECEIVED, form a SYN,ACK segment

               <SEQ=ISS><ACK=RCV.NXT><CTL=SYN,ACK>

            and send it.  Set the variables:

               SND.WND <- SEG.WND
               SND.WL1 <- SEG.SEQ
               SND.WL2 <- SEG.ACK

            If there are other controls or text in the segment, queue
            them for processing after the ESTABLISHED state has been
            reached, return.

            Note that it is legal to send and receive application data
            on SYN segments (this is the "text in the segment" mentioned

Eddy                      Expires May 16, 2018                 [Page 69]
Internet-Draft              TCP Specification              November 2017

            above.  There has been significant misinformation and
            misunderstanding of this topic historically.  Some firewalls
            and security devices consider this suspicious.  However, the
            capability was used in T/TCP [15] and is used in TCP Fast
            Open (TFO) [32], so is important for implementations and
            network devices to permit.

         fifth, if neither of the SYN or RST bits is set then drop the
         segment and return.

      Otherwise,

      first check sequence number

         SYN-RECEIVED STATE
         ESTABLISHED STATE
         FIN-WAIT-1 STATE
         FIN-WAIT-2 STATE
         CLOSE-WAIT STATE
         CLOSING STATE
         LAST-ACK STATE
         TIME-WAIT STATE

            Segments are processed in sequence.  Initial tests on
            arrival are used to discard old duplicates, but further
            processing is done in SEG.SEQ order.  If a segment's
            contents straddle the boundary between old and new, only the
            new parts should be processed.

            There are four cases for the acceptability test for an
            incoming segment:

         Segment Receive  Test
         Length  Window
         ------- -------  -------------------------------------------

            0       0     SEG.SEQ = RCV.NXT

            0      >0     RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND

           >0       0     not acceptable

           >0      >0     RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
                       or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND

Eddy                      Expires May 16, 2018                 [Page 70]
Internet-Draft              TCP Specification              November 2017

            If the RCV.WND is zero, no segments will be acceptable, but
            special allowance should be made to accept valid ACKs, URGs
            and RSTs.

            If an incoming segment is not acceptable, an acknowledgment
            should be sent in reply (unless the RST bit is set, if so
            drop the segment and return):

               <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

            After sending the acknowledgment, drop the unacceptable
            segment and return.

            Note that for the TIME-WAIT state, there is an improved
            algorithm described in [26] for handling incoming SYN
            segments, that utilizes timestamps rather than relying on
            the sequence number check described here.  When the improved
            algorithm is implemented, the logic above is not applicable
            for incoming SYN segments with timestamp options, received
            on a connection in the TIME-WAIT state.

            In the following it is assumed that the segment is the
            idealized segment that begins at RCV.NXT and does not exceed
            the window.  One could tailor actual segments to fit this
            assumption by trimming off any portions that lie outside the
            window (including SYN and FIN), and only processing further
            if the segment then begins at RCV.NXT.  Segments with higher
            beginning sequence numbers should be held for later
            processing.

            In general, the processing of received segments MUST be
            implemented to aggregate ACK segments whenever possible.
            For example, if the TCP is processing a series of queued
            segments, it MUST process them all before sending any ACK
            segments.  (TODO - see if there's a better place for this
            paragraph - taken from RFC1122)

         second check the RST bit,

            RFC 5961 section 3 describes a potential blind reset attack
            and optional mitigation approach that SHOULD be implemented.
            For stacks implementing RFC 5961, the three checks below
            apply, otherwise processesing for these states is indicated
            further below.

               1) If the RST bit is set and the sequence number is
               outside the current receive window, silently drop the
               segment.

Eddy                      Expires May 16, 2018                 [Page 71]
Internet-Draft              TCP Specification              November 2017

               2) If the RST bit is set and the sequence number exactly
               matches the next expected sequence number (RCV.NXT), then
               TCP MUST reset the connection in the manner prescribed
               below according to the connection state.

               3) If the RST bit is set and the sequence number does not
               exactly match the next expected sequence value, yet is
               within the current receive window, TCP MUST send an
               acknowledgement (challenge ACK):

               <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

               After sending the challenge ACK, TCP MUST drop the
               unacceptable segment and stop processing the incoming
               packet further.  Note that RFC 5961 and Errata ID 4772
               contain additional considerations for ACK throttling in
               an implementation.

            SYN-RECEIVED STATE

               If the RST bit is set

                  If this connection was initiated with a passive OPEN
                  (i.e., came from the LISTEN state), then return this
                  connection to LISTEN state and return.  The user need
                  not be informed.  If this connection was initiated
                  with an active OPEN (i.e., came from SYN-SENT state)
                  then the connection was refused, signal the user
                  "connection refused".  In either case, all segments on
                  the retransmission queue should be removed.  And in
                  the active OPEN case, enter the CLOSED state and
                  delete the TCB, and return.

            ESTABLISHED
            FIN-WAIT-1
            FIN-WAIT-2
            CLOSE-WAIT

               If the RST bit is set then, any outstanding RECEIVEs and
               SEND should receive "reset" responses.  All segment
               queues should be flushed.  Users should also receive an
               unsolicited general "connection reset" signal.  Enter the
               CLOSED state, delete the TCB, and return.

            CLOSING STATE
            LAST-ACK STATE
            TIME-WAIT

Eddy                      Expires May 16, 2018                 [Page 72]
Internet-Draft              TCP Specification              November 2017

               If the RST bit is set then, enter the CLOSED state,
               delete the TCB, and return.

         third check security and precedence

            SYN-RECEIVED

               If the security/compartment and precedence in the segment
               do not exactly match the security/compartment and
               precedence in the TCB then send a reset, and return.

            ESTABLISHED
            FIN-WAIT-1
            FIN-WAIT-2
            CLOSE-WAIT
            CLOSING
            LAST-ACK
            TIME-WAIT

               If the security/compartment and precedence in the segment
               do not exactly match the security/compartment and
               precedence in the TCB then send a reset, any outstanding
               RECEIVEs and SEND should receive "reset" responses.  All
               segment queues should be flushed.  Users should also
               receive an unsolicited general "connection reset" signal.
               Enter the CLOSED state, delete the TCB, and return.

            Note this check is placed following the sequence check to
            prevent a segment from an old connection between these ports
            with a different security or precedence from causing an
            abort of the current connection.

         fourth, check the SYN bit,

            SYN-RECEIVED

               If the connection was initiated with a passive OPEN, then
               return this connection to the LISTEN state and return.
               Otherwise, handle per the directions for synchronized
               states below.

            ESTABLISHED STATE
            FIN-WAIT STATE-1
            FIN-WAIT STATE-2
            CLOSE-WAIT STATE
            CLOSING STATE
            LAST-ACK STATE

Eddy                      Expires May 16, 2018                 [Page 73]
Internet-Draft              TCP Specification              November 2017

            TIME-WAIT STATE

               If the SYN bit is set in these synchronized states, it
               may be either a legitimate new connection attempt (e.g.
               in the case of TIME-WAIT), an error where the connection
               should be reset, or the result of an attack attempt, as
               described in RFC 5961 [24].  For the TIME-WAIT state, new
               connections can be accepted if the timestamp option is
               used and meets expectations (per [26]).  For all other
               caess, RFC 5961 provides a mitigation that SHOULD be
               implemented, though there are alternatives (see
               Section 6).  RFC 5961 recommends that in these
               synchronized states, if the SYN bit is set, irrespective
               of the sequence number, TCP MUST send a "challenge ACK"
               to the remote peer:

               <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

               After sending the acknowledgement, TCP MUST drop the
               unacceptable segment and stop processing further.  Note
               that RFC 5961 and Errata ID 4772 contain additional ACK
               throttling notes for an implementation.

               For implementations that do not follow RFC 5961, the
               original RFC 793 behavior follows in this paragraph.  If
               the SYN is in the window it is an error, send a reset,
               any outstanding RECEIVEs and SEND should receive "reset"
               responses, all segment queues should be flushed, the user
               should also receive an unsolicited general "connection
               reset" signal, enter the CLOSED state, delete the TCB,
               and return.

               If the SYN is not in the window this step would not be
               reached and an ack would have been sent in the first step
               (sequence number check).

         fifth check the ACK field,

            if the ACK bit is off drop the segment and return

            if the ACK bit is on

               RFC 5961 section 5 describes a potential blind data
               injection attack, and mitigation that implementations MAY
               choose to include.  TCP stacks that implement RFC 5961
               MUST add an input check that the ACK value is acceptable
               only if it is in the range of ((SND.UNA - MAX.SND.WND) =<
               SEG.ACK =< SND.NXT).  All incoming segments whose ACK

Eddy                      Expires May 16, 2018                 [Page 74]
Internet-Draft              TCP Specification              November 2017

               value doesn't satisfy the above condition MUST be
               discarded and an ACK sent back.  The new state variable
               MAX.SND.WND is defined as the largest window that the
               local sender has ever received from its peer (subject to
               window scaling) or may be hard-coded to a maximum
               permissible window value.  When the ACK value is
               acceptable, the processing per-state below applies:

               SYN-RECEIVED STATE

                  If SND.UNA < SEG.ACK =< SND.NXT then enter ESTABLISHED
                  state and continue processing with variables below set
                  to:

                     SND.WND <- SEG.WND
                     SND.WL1 <- SEG.SEQ
                     SND.WL2 <- SEG.ACK

                     If the segment acknowledgment is not acceptable,
                     form a reset segment,

                        <SEQ=SEG.ACK><CTL=RST>

                     and send it.

               ESTABLISHED STATE

                  If SND.UNA < SEG.ACK =< SND.NXT then, set SND.UNA <-
                  SEG.ACK.  Any segments on the retransmission queue
                  which are thereby entirely acknowledged are removed.
                  Users should receive positive acknowledgments for
                  buffers which have been SENT and fully acknowledged
                  (i.e., SEND buffer should be returned with "ok"
                  response).  If the ACK is a duplicate (SEG.ACK =<
                  SND.UNA), it can be ignored.  If the ACK acks
                  something not yet sent (SEG.ACK > SND.NXT) then send
                  an ACK, drop the segment, and return.

                  If SND.UNA =< SEG.ACK =< SND.NXT, the send window
                  should be updated.  If (SND.WL1 < SEG.SEQ or (SND.WL1
                  = SEG.SEQ and SND.WL2 =< SEG.ACK)), set SND.WND <-
                  SEG.WND, set SND.WL1 <- SEG.SEQ, and set SND.WL2 <-
                  SEG.ACK.

                  Note that SND.WND is an offset from SND.UNA, that
                  SND.WL1 records the sequence number of the last
                  segment used to update SND.WND, and that SND.WL2
                  records the acknowledgment number of the last segment

Eddy                      Expires May 16, 2018                 [Page 75]
Internet-Draft              TCP Specification              November 2017

                  used to update SND.WND.  The check here prevents using
                  old segments to update the window.

               FIN-WAIT-1 STATE

                  In addition to the processing for the ESTABLISHED
                  state, if our FIN is now acknowledged then enter FIN-
                  WAIT-2 and continue processing in that state.

               FIN-WAIT-2 STATE

                  In addition to the processing for the ESTABLISHED
                  state, if the retransmission queue is empty, the
                  user's CLOSE can be acknowledged ("ok") but do not
                  delete the TCB.

               CLOSE-WAIT STATE

                  Do the same processing as for the ESTABLISHED state.

               CLOSING STATE

                  In addition to the processing for the ESTABLISHED
                  state, if the ACK acknowledges our FIN then enter the
                  TIME-WAIT state, otherwise ignore the segment.

               LAST-ACK STATE

                  The only thing that can arrive in this state is an
                  acknowledgment of our FIN.  If our FIN is now
                  acknowledged, delete the TCB, enter the CLOSED state,
                  and return.

               TIME-WAIT STATE

                  The only thing that can arrive in this state is a
                  retransmission of the remote FIN.  Acknowledge it, and
                  restart the 2 MSL timeout.

         sixth, check the URG bit,

            ESTABLISHED STATE
            FIN-WAIT-1 STATE
            FIN-WAIT-2 STATE

               If the URG bit is set, RCV.UP <- max(RCV.UP,SEG.UP), and
               signal the user that the remote side has urgent data if
               the urgent pointer (RCV.UP) is in advance of the data

Eddy                      Expires May 16, 2018                 [Page 76]
Internet-Draft              TCP Specification              November 2017

               consumed.  If the user has already been signaled (or is
               still in the "urgent mode") for this continuous sequence
               of urgent data, do not signal the user again.

            CLOSE-WAIT STATE
            CLOSING STATE
            LAST-ACK STATE
            TIME-WAIT

               This should not occur, since a FIN has been received from
               the remote side.  Ignore the URG.

         seventh, process the segment text,

            ESTABLISHED STATE
            FIN-WAIT-1 STATE
            FIN-WAIT-2 STATE

               Once in the ESTABLISHED state, it is possible to deliver
               segment text to user RECEIVE buffers.  Text from segments
               can be moved into buffers until either the buffer is full
               or the segment is empty.  If the segment empties and
               carries an PUSH flag, then the user is informed, when the
               buffer is returned, that a PUSH has been received.

               When the TCP takes responsibility for delivering the data
               to the user it must also acknowledge the receipt of the
               data.

               Once the TCP takes responsibility for the data it
               advances RCV.NXT over the data accepted, and adjusts
               RCV.WND as appropriate to the current buffer
               availability.  The total of RCV.NXT and RCV.WND should
               not be reduced.

               A TCP MAY send an ACK segment acknowledging RCV.NXT when
               a valid segment arrives that is in the window but not at
               the left window edge.

               Please note the window management suggestions in section
               3.7.

               Send an acknowledgment of the form:

                  <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>

Eddy                      Expires May 16, 2018                 [Page 77]
Internet-Draft              TCP Specification              November 2017

               This acknowledgment should be piggybacked on a segment
               being transmitted if possible without incurring undue
               delay.

            CLOSE-WAIT STATE
            CLOSING STATE
            LAST-ACK STATE
            TIME-WAIT STATE

               This should not occur, since a FIN has been received from
               the remote side.  Ignore the segment text.

         eighth, check the FIN bit,

            Do not process the FIN if the state is CLOSED, LISTEN or
            SYN-SENT since the SEG.SEQ cannot be validated; drop the
            segment and return.

            If the FIN bit is set, signal the user "connection closing"
            and return any pending RECEIVEs with same message, advance
            RCV.NXT over the FIN, and send an acknowledgment for the
            FIN.  Note that FIN implies PUSH for any segment text not
            yet delivered to the user.

               SYN-RECEIVED STATE
               ESTABLISHED STATE

                  Enter the CLOSE-WAIT state.

               FIN-WAIT-1 STATE

                  If our FIN has been ACKed (perhaps in this segment),
                  then enter TIME-WAIT, start the time-wait timer, turn
                  off the other timers; otherwise enter the CLOSING
                  state.

               FIN-WAIT-2 STATE

                  Enter the TIME-WAIT state.  Start the time-wait timer,
                  turn off the other timers.

               CLOSE-WAIT STATE

                  Remain in the CLOSE-WAIT state.

               CLOSING STATE

                  Remain in the CLOSING state.

Eddy                      Expires May 16, 2018                 [Page 78]
Internet-Draft              TCP Specification              November 2017

               LAST-ACK STATE

                  Remain in the LAST-ACK state.

               TIME-WAIT STATE

                  Remain in the TIME-WAIT state.  Restart the 2 MSL
                  time-wait timeout.

         and return.

Eddy                      Expires May 16, 2018                 [Page 79]
Internet-Draft              TCP Specification              November 2017

   USER TIMEOUT

      USER TIMEOUT

         For any state if the user timeout expires, flush all queues,
         signal the user "error: connection aborted due to user timeout"
         in general and for any outstanding calls, delete the TCB, enter
         the CLOSED state and return.

      RETRANSMISSION TIMEOUT

         For any state if the retransmission timeout expires on a
         segment in the retransmission queue, send the segment at the
         front of the retransmission queue again, reinitialize the
         retransmission timer, and return.

      TIME-WAIT TIMEOUT

         If the time-wait timeout expires on a connection delete the
         TCB, enter the CLOSED state and return.

Eddy                      Expires May 16, 2018                 [Page 80]
Internet-Draft              TCP Specification              November 2017

3.11.  Glossary

   1822    BBN Report 1822, "The Specification of the Interconnection of
           a Host and an IMP".  The specification of interface between a
           host and the ARPANET.

   ACK
           A control bit (acknowledge) occupying no sequence space,
           which indicates that the acknowledgment field of this segment
           specifies the next sequence number the sender of this segment
           is expecting to receive, hence acknowledging receipt of all
           previous sequence numbers.

   ARPANET message
           The unit of transmission between a host and an IMP in the
           ARPANET.  The maximum size is about 1012 octets (8096 bits).

   ARPANET packet
           A unit of transmission used internally in the ARPANET between
           IMPs.  The maximum size is about 126 octets (1008 bits).

   connection
           A logical communication path identified by a pair of sockets.

   datagram
           A message sent in a packet switched computer communications
           network.

   Destination Address
           The destination address, usually the network and host
           identifiers.

   FIN
           A control bit (finis) occupying one sequence number, which
           indicates that the sender will send no more data or control
           occupying sequence space.

   fragment
           A portion of a logical unit of data, in particular an
           internet fragment is a portion of an internet datagram.

   FTP
           A file transfer protocol.

   header
           Control information at the beginning of a message, segment,
           fragment, packet or block of data.

Eddy                      Expires May 16, 2018                 [Page 81]
Internet-Draft              TCP Specification              November 2017

   host
           A computer.  In particular a source or destination of
           messages from the point of view of the communication network.

   Identification
           An Internet Protocol field.  This identifying value assigned
           by the sender aids in assembling the fragments of a datagram.

   IMP
           The Interface Message Processor, the packet switch of the
           ARPANET.

   internet address
           A source or destination address specific to the host level.

   internet datagram
           The unit of data exchanged between an internet module and the
           higher level protocol together with the internet header.

   internet fragment
           A portion of the data of an internet datagram with an
           internet header.

   IP
           Internet Protocol.

   IRS
           The Initial Receive Sequence number.  The first sequence
           number used by the sender on a connection.

   ISN
           The Initial Sequence Number.  The first sequence number used
           on a connection, (either ISS or IRS).  Selected in a way that
           is unique within a given period of time and is unpredictable
           to attackers.

   ISS
           The Initial Send Sequence number.  The first sequence number
           used by the sender on a connection.

   leader
           Control information at the beginning of a message or block of
           data.  In particular, in the ARPANET, the control information
           on an ARPANET message at the host-IMP interface.

   left sequence
           This is the next sequence number to be acknowledged by the
           data receiving TCP (or the lowest currently unacknowledged

Eddy                      Expires May 16, 2018                 [Page 82]
Internet-Draft              TCP Specification              November 2017

           sequence number) and is sometimes referred to as the left
           edge of the send window.

   local packet
           The unit of transmission within a local network.

   module
           An implementation, usually in software, of a protocol or
           other procedure.

   MSL
           Maximum Segment Lifetime, the time a TCP segment can exist in
           the internetwork system.  Arbitrarily defined to be 2
           minutes.

   octet
           An eight bit byte.

   Options
           An Option field may contain several options, and each option
           may be several octets in length.  The options are used
           primarily in testing situations; for example, to carry
           timestamps.  Both the Internet Protocol and TCP provide for
           options fields. -- TODO not primarily testing anymore!

   packet
           A package of data with a header which may or may not be
           logically complete.  More often a physical packaging than a
           logical packaging of data.

   port
           The portion of a socket that specifies which logical input or
           output channel of a process is associated with the data.

   process
           A program in execution.  A source or destination of data from
           the point of view of the TCP or other host-to-host protocol.

   PUSH
           A control bit occupying no sequence space, indicating that
           this segment contains data that must be pushed through to the
           receiving user.

   RCV.NXT
           receive next sequence number

   RCV.UP
           receive urgent pointer

Eddy                      Expires May 16, 2018                 [Page 83]
Internet-Draft              TCP Specification              November 2017

   RCV.WND
           receive window

   receive next sequence number
           This is the next sequence number the local TCP is expecting
           to receive.

   receive window
           This represents the sequence numbers the local (receiving)
           TCP is willing to receive.  Thus, the local TCP considers
           that segments overlapping the range RCV.NXT to RCV.NXT +
           RCV.WND - 1 carry acceptable data or control.  Segments
           containing sequence numbers entirely outside of this range
           are considered duplicates and discarded.

   RST
           A control bit (reset), occupying no sequence space,
           indicating that the receiver should delete the connection
           without further interaction.  The receiver can determine,
           based on the sequence number and acknowledgment fields of the
           incoming segment, whether it should honor the reset command
           or ignore it.  In no case does receipt of a segment
           containing RST give rise to a RST in response.

   RTP
           Real Time Protocol: A host-to-host protocol for communication
           of time critical information.

   SEG.ACK
           segment acknowledgment

   SEG.LEN
           segment length

   SEG.PRC
           segment precedence value

   SEG.SEQ
           segment sequence

   SEG.UP
           segment urgent pointer field

   SEG.WND
           segment window field

   segment

Eddy                      Expires May 16, 2018                 [Page 84]
Internet-Draft              TCP Specification              November 2017

           A logical unit of data, in particular a TCP segment is the
           unit of data transfered between a pair of TCP modules.

   segment acknowledgment
           The sequence number in the acknowledgment field of the
           arriving segment.

   segment length
           The amount of sequence number space occupied by a segment,
           including any controls which occupy sequence space.

   segment sequence
           The number in the sequence field of the arriving segment.

   send sequence
           This is the next sequence number the local (sending) TCP will
           use on the connection.  It is initially selected from an
           initial sequence number curve (ISN) and is incremented for
           each octet of data or sequenced control transmitted.

   send window
           This represents the sequence numbers which the remote
           (receiving) TCP is willing to receive.  It is the value of
           the window field specified in segments from the remote (data
           receiving) TCP.  The range of new sequence numbers which may
           be emitted by a TCP lies between SND.NXT and SND.UNA +
           SND.WND - 1.  (Retransmissions of sequence numbers between
           SND.UNA and SND.NXT are expected, of course.)

   SND.NXT
           send sequence

   SND.UNA
           left sequence

   SND.UP
           send urgent pointer

   SND.WL1
           segment sequence number at last window update

   SND.WL2
           segment acknowledgment number at last window update

   SND.WND
           send window

   socket

Eddy                      Expires May 16, 2018                 [Page 85]
Internet-Draft              TCP Specification              November 2017

           An address which specifically includes a port identifier,
           that is, the concatenation of an Internet Address with a TCP
           port.

   Source Address
           The source address, usually the network and host identifiers.

   SYN
           A control bit in the incoming segment, occupying one sequence
           number, used at the initiation of a connection, to indicate
           where the sequence numbering will start.

   TCB
           Transmission control block, the data structure that records
           the state of a connection.

   TCB.PRC
           The precedence of the connection.

   TCP
           Transmission Control Protocol: A host-to-host protocol for
           reliable communication in internetwork environments.

   TOS
           Type of Service, an IPv4 field, that currently carries the
           Differentiated Services field [6] containing the
           Differentiated Services Code Point (DSCP) value and two
           unused bits.

   Type of Service
           An Internet Protocol field which indicates the type of
           service for this internet fragment.

   URG
           A control bit (urgent), occupying no sequence space, used to
           indicate that the receiving user should be notified to do
           urgent processing as long as there is data to be consumed
           with sequence numbers less than the value indicated in the
           urgent pointer.

   urgent pointer
           A control field meaningful only when the URG bit is on.  This
           field communicates the value of the urgent pointer which
           indicates the data octet associated with the sending user's
           urgent call.

Eddy                      Expires May 16, 2018                 [Page 86]
Internet-Draft              TCP Specification              November 2017

4.  Changes from RFC 793

   This document obsoletes RFC 793 as well as RFC 6093 and 6528, which
   updated 793.  In all cases, only the normative protocol specification
   and requirements have been incorporated into this document, and the
   informational text with background and rationale has not been carried
   in.  The informational content of those documents is still valuable
   in learning about and understanding TCP, and they are valid
   Informational references, even though their normative content has
   been incorporated into this document.

   The main body of this document was adapted from RFC 793's Section 3,
   titled "FUNCTIONAL SPECIFICATION", with an attempt to keep formatting
   and layout as close as possible.

   The collection of applicable RFC Errata that have been reported and
   either accepted or held for an update to RFC 793 were incorporated
   (Errata IDs: 573, 574, 700, 701, 1283, 1561, 1562, 1564, 1565, 1571,
   1572, 2296, 2297, 2298, 2748, 2749, 2934, 3213, 3300, 3301).  Some
   errata were not applicable due to other changes (Errata IDs: 572,
   575, 1569, 3602).  TODO: 3305

   Changes to the specification of the Urgent Pointer described in RFC
   1122 and 6093 were incorporated.  See RFC 6093 for detailed
   discussion of why these changes were necessary.

   The discussion of the RTO from RFC 793 was updated to refer to RFC
   6298.  The RFC 1122 text on the RTO originally replaced the 793 text,
   however, RFC 2988 should have updated 1122, and has subsequently been
   obsoleted by 6298.

   RFC 1122 contains a collection of other changes and clarifications to
   RFC 793.  The normative items impacting the protocol have been
   incorporated here, though some historically useful implementation
   advice and informative discussion from RFC 1122 is not included here.

   RFC 1122 contains more than just TCP requirements, so this document
   can't obsolete RFC 1122 entirely.  It is only marked as "updating"
   1122, however, it should be understood to effectively obsolete all of
   the RFC 1122 material on TCP.

   The more secure Initial Sequence Number generation algorithm from RFC
   6528 was incorporated.  See RFC 6528 for discussion of the attacks
   that this mitigates, as well as advice on selecting PRF algorithms
   and managing secret key data.

   A note based on RFC 6429 was added to explicitly clarify that system
   resource mangement concerns allow connection resources to be

Eddy                      Expires May 16, 2018                 [Page 87]
the vulnerabilities on the management objects within the AN MIB
   module.  These attacks mainly concern the unauthorized changes of the
   management objects, leading to a number of attacks such as session
   deletion, a session using an undesired/unsupported protocol,
   disabling certain ANCP capabilities or enabling undesired
   capabilities, ANCP packets being sent out to the wrong interface (and
   thus being received by an unintended receiver), harming the
   synchronization between the AN and the NAS, and impacting traffic in
   the network other than ANCP.

6.  Attack Forms

   The attacks mentioned above in Section 5 can be carried out through
   the following means:

   Message Replay:

      This threat scenario covers the case in which an adversary
      eavesdrops, collects signaling messages, and replays them at a
      later time (or at a different place or in a different way; e.g.,
      cut-and-paste attacks).  Through replaying signaling messages, an
      adversary might mount denial-of-service and theft-of-service
      attacks.

   Faked Message Injection:

      An adversary may be able to inject false error or response
      messages, causing unexpected protocol behavior and succeeding with
      a DoS attack.  This could be achieved at the signaling-protocol
      level, at the level of specific signaling parameters (e.g., QoS
      information), or at the transport layer.  An adversary might, for
      example, inject a signaling message to request allocation of QoS
      resources.  As a consequence, other users' traffic might be
      impacted.  The discovery protocol, especially, exhibits
      vulnerabilities with regard to this threat scenario.

   Messages Modification:

      This involves integrity violation, where an adversary can modify
      signaling messages in order to cause unexpected network behavior.
      Possible related actions an adversary might consider for its
      attack are the reordering and delaying of messages, causing a
      protocol's process failure.

Moustafa, et al.             Informational                      [Page 9]
RFC 5713                      ANCP Threats                  January 2010

   Man-in-the-Middle:

      An adversary might claim to be a NAS or an AN, acting as a man-in-
      the-middle to later cause communication and services disruption.
      The consequence can range from DoS to fraud.  An adversary acting
      as a man-in-the-middle could modify the intercepted messages,
      causing integrity violation, or could drop or truncate the
      intercepted messages, causing DoS and a protocol's process
      failure.  In addition, a man-in-the-middle adversary can signal
      information to an illegitimate entity in place of the right
      destination.  In this case, the protocol could appear to continue
      working correctly.  This may result in an AN contacting a wrong
      NAS.  For the AN, this could mean that the protocol failed for
      unknown reasons.  A man-in-the-middle adversary can also cause
      downgrading attacks through initiating faked configuration
      parameters and through forcing selection of weak security
      parameters or mechanisms.

   Eavesdropping:

      This is related to adversaries that are able to eavesdrop on
      transferred messages.  The collection of the transferred packets
      by an adversary may allow traffic analysis or be used later to
      mount replay attacks.  The eavesdropper might learn QoS
      parameters, communication patterns, policy rules for firewall
      traversal, policy information, application identifiers, user
      identities, NAT bindings, authorization objects, network
      configuration, performance information, and more.

7.  Attacks against ANCP

   ANCP is susceptible to security threats, causing disruption/
   unauthorized access to network services, manipulation of the
   transferred data, and interference with network functions.  Based on
   the threat model given in Section 3 and the potential attacks
   presented in Section 5, this section describes the possible attacks
   against ANCP, considering the four use cases defined in [ANCP-FRAME].

   Although ANCP is not involved in the communication between the NAS
   and the AAA/policy server, the secure communication between the NAS
   and the AAA/policy server is important for ANCP security.
   Consequently, this document considers the attacks that are related to
   the ANCP operation associated with the communication between the NAS
   and the AAA/Policy server.  In other words, the threat model and
   security requirements in this document take into consideration the
   data transfer between the NAS and the AAA server, when this data is
   used within the ANCP operation.

Moustafa, et al.             Informational                     [Page 10]
RFC 5713                      ANCP Threats                  January 2010

   Besides the attacks against the four ANCP use cases described in the
   following subsections, ANCP is susceptible to a number of attacks
   that can take place during the protocol-establishment phase.  These
   attacks are mainly on-path attacks, taking the form of DoS or man-in-
   the-middle attacks, which could be as follows:

   o  Attacks during the session initiation from the AN to the NAS:
      DoS attacks could take place affecting the session-establishment
      process.  Also, man-in-the-middle attacks could take place,
      causing message truncation or message modification and leading to
      session-establishment failure.

   o  Attacks during the peering establishment:
      DoS attacks could take place during state synchronization between
      the AN and the NAS.  Also, man-in-the-middle attacks could take
      place through message modification during identity discovery,
      which may lead to loss of contact between the AN and the NAS.

   o  Attacks during capabilities negotiation:
      Message replay could take place, leading to DoS.  Also, man-in-
      the-middle attacks could take place, leading to message
      modification, message truncation, or downgrading through
      advertising lesser capabilities.

7.1.  Dynamic Access-Loop Attributes

   This use case concerns the communication of access-loop attributes
   for dynamic, access-line topology discovery.  Since the access-loop
   rate may change over time, advertisement is beneficial to the NAS to
   gain knowledge about the topology of the access network for QoS
   scheduling.  Besides data rates and access-loop links identification,
   other information may also be transferred from the AN to the NAS
   (examples in case of a DSL access loop are DSL type, maximum
   achievable data rate, and maximum data rate configured for the access
   loop).  This use case is thus vulnerable to a number of on-path and
   off-path attacks that can be either active or passive.

   On-path attacks can take place between the AN and the NAS, on the AN
   or on the NAS, during the access-loop attributes transfer.  These
   attacks may be:

   o  Active, acting on the transferred attributes and injecting
      falsified packets.  The main attacks here are:

      *  Man-in-the-middle attacks can cause access-loop attributes
         transfer between the AN and a forged NAS or a forged AN and the
         NAS, which can directly cause faked attributes and message
         modification or truncation.

Moustafa, et al.             Informational                     [Page 11]
RFC 5713                      ANCP Threats                  January 2010

      *  Signaling replay, by an attacker between the AN and the NAS, on
         the AN or on the NAS itself, causing DoS.

      *  An adversary acting as man-in-the-middle can cause downgrading
         through changing the actual data rate of the access loop, which
         impacts the downstream shaping from the NAS.

   o  Passive, only learning these attributes.  The main attacks here
      are caused by:

      *  Eavesdropping through learning access-loop attributes and
         information about the clients' connection state, and thus
         impacting their privacy protection.

      *  Traffic analysis allowing unauthorized information access,
         which could allow later unauthorized access to the NAS.

   Off-path attacks can take place on the Internet, affecting the
   access-loop attribute sharing between the NAS and the AAA/policy
   server.  These attacks may be:

   o  Active attacks, which are mainly concerning:

      *  DoS through flooding the communication links to the AAA/policy
         server, causing service disruption.

      *  Man-in-the-middle, causing access-loop configuration retrieval
         by an illegitimate NAS.

   o  Passive attacks, gaining information on the access-loop
      attributes.  The main attacks in this case are:

      *  Eavesdropping through learning access-loop attributes and
         learning information about the clients' connection states, and
         thus impacting their privacy protection.

      *  Traffic analysis allowing unauthorized information access,
         which could allow later unauthorized access to the NAS.

7.2.  Access-Loop Configuration

   This use case concerns the dynamic, local-loop line configuration
   through allowing the NAS to change the access-loop parameters (e.g.,
   rate) in a dynamic fashion.  This allows for centralized, subscriber-
   related service data.  This dynamic configuration can be achieved,
   for instance, through profiles that are pre-configured on ANs.  This
   use case is vulnerable to a number of on-path and off-path attacks.

Moustafa, et al.             Informational                     [Page 12]
RFC 5713                      ANCP Threats                  January 2010

   On-path attacks can take place where the attacker is between the AN
   and the NAS, is on the AN, or is on the NAS.  These can be as
   follows:

   o  Active attacks, taking the following forms:

      *  DoS attacks of the AN can take place by an attacker, through
         replaying the Configure Request messages.

      *  An attacker on the AN can prevent the AN from reacting on the
         NAS request for the access-loop configuration, leading to the
         NAS continually sending the Configure Request message and,
         hence, allocating additional states.

      *  Damaging clients' profiles at ANs can take place by adversaries
         that gained control on the network through discovery of users'
         information from a previous traffic analysis.

      *  An adversary can replay old packets, modify messages, or inject
         faked messages.  Such adversary can also be a man-in-the-
         middle.  These attack forms can be related to a privileged
         client profile (having more services) in order to configure
         this profile on the adversary's own DSL line, which is less
         privileged.  In order that the attacker does not expose its
         identity, he may also use these attack forms related to the
         privileged client profile to configure a number of illegitimate
         DSL lines.  The adversary can also force configuration
         parameters other than the selected ones, leading to, for
         instance, downgrading the service for a privileged client.

   o  Passive attacks, where the attacker listens to the ANCP messages.
      This can take place as follows:

      *  Learning configuration attributes is possible during the update
         of the access-loop configuration.  An adversary might profit to
         see the configuration that someone else gets (e.g., one ISP
         might be interested to know what the customers of another ISP
         get and therefore might break into the AN to see this).

   Off-path attacks can take place as follows:

   o  An off-path passive adversary on the Internet can exert
      eavesdropping during the access-loop configuration retrieval by
      the NAS from the AAA/policy server.

Moustafa, et al.             Informational                     [Page 13]
RFC 5713                      ANCP Threats                  January 2010

   o  An off-path active adversary on the Internet can threaten the
      centralized subscribers-related service data in the AAA/policy
      server through, for instance, making subscribers' records
      inaccessible.

7.3.  Remote Connectivity Test

   In this use case, the NAS can carry out a Remote Connectivity Test
   using ANCP to initiate an access-loop test between the AN and the
   HGW.  Thus, multiple access-loop technologies can be supported.  This
   use case is vulnerable to a number of active attacks.  Most of the
   attacks in this use case concern the network operation.

   On-path active attacks can take place in the following forms:

   o  Man-in-the-middle attack during the NAS's triggering to the AN to
      carry out the test, where an adversary can inject falsified
      signals or can truncate the triggering.

   o  Message modification can take place during the Subscriber Response
      message transfer from the AN to the NAS announcing the test
      results, causing failure of the test operation.

   o  An adversary on the AN can prevent the AN from sending the
      Subscriber Response message to the NAS announcing the test
      results, and hence the NAS will continue triggering the AN to
      carry out the test, which results in more state being allocated at
      the NAS.  This may result in unavailability of the NAS to the ANs.

   Off-path active attacks can take place as follows:

   o  An adversary can cause DoS during the access-loop test, in case of
      an ATM-based access loop, when the AN generates loopback cells.
      This can take place through signal replaying.

   o  Message truncating can take place by an adversary during the
      access-loop test, which can lead to service disruption due to
      assumption of test failures.

7.4.  Multicast

   In this use case, ANCP could be used in exchanging information
   between the AN and the NAS, allowing the AN to perform replication
   inline with the policy and configuration of the subscriber.  Also,
   this allows the NAS to follow subscribers' multicast (source, group)
   membership and control replication performed by the AN.  Four
   multicast use cases are expected to take place, making use of ANCP;
   these are typically multicast conditional access, multicast admission

Moustafa, et al.             Informational                     [Page 14]
RFC 5713                      ANCP Threats                  January 2010

   control, multicast accounting, and spontaneous admission response.
   This section gives a high-level description of the possible attacks
   that can take place in these cases.  Attacks that can occur are
   mostly active attacks.

   On-path active attacks can be as follows:

   o  DoS attacks, causing inability for certain subscribers to access
      particular multicast streams or only access the multicast stream
      at a reduced bandwidth, impacting the quality of the possible
      video stream.  This can take place through message replay by an
      attacker between the AN and the NAS, on the AN or on the NAS.
      Such DoS attacks can also be done by tempering, for instance, with
      white/black list configuration or by placing attacks to the
      bandwidth-admission-control mechanism.

   o  An adversary on the NAS can prevent the NAS from reacting on the
      AN requests for white/black/grey lists or for admission control
      for the access line.  The AN in this case would not receive a
      reply and would continue sending its requests, resulting in more
      states being allocated at the AN.  A similar case happens for
      admission control when the NAS can also send requests to the AN.
      When the NAS does not receive a response, it could also retransmit
      requests, resulting in more state being allocated at the NAS side
      to process responses.  This may result in the unavailability of
      the NAS to the ANs.

   o  Man-in-the-middle, causing the exchange of messages between the AN
      and a forged NAS or a forged AN and the NAS.  This can lead to the
      following:

      *  Message modification, which can cause service downgrading for
         legitimate subscribers -- for instance, an illegitimate change
         of a subscriber's policy.

      *  Message truncation between the AN and the NAS, which can result
         in the non-continuity of services.

      *  Message replay between the AN and the NAS, on the AN or on the
         NAS, leading to a DoS or services fraud.

      *  Message modification to temper with accounting information, for
         example, in order to avoid service charges or, conversely, in
         order to artificially increase service charges on other users.

Moustafa, et al.             Informational                     [Page 15]
RFC 5713                      ANCP Threats                  January 2010

   An off-path active attack is as follows:

   o  DoS could take place through message replay of join/leave requests
      by the HGW or CPE, frequently triggering the ANCP activity between
      the AN and the NAS.  DoS could also result from generating heaps
      of IGMP join/leaves by the HGW or CPE, leading to very high rate
      of ANCP query/response.

8.  Security Requirements

   This section presents a number of requirements motivated by the
   different types of attacks defined in the previous section.  These
   requirements are as follows:

   o  The protocol solution MUST offer authentication of the AN to the
      NAS.

   o  The protocol solution MUST offer authentication of the NAS to the
      AN.

   o  The protocol solution MUST allow authorization to take place at
      the NAS and the AN.

   o  The protocol solution MUST offer replay protection.

   o  The protocol solution MUST provide data-origin authentication.

   o  The protocol solution MUST be robust against denial-of-service
      (DoS) attacks.  In this context, the protocol solution MUST
      consider a specific mechanism for the DoS that the user might
      create by sending many IGMP messages.

   o  The protocol solution SHOULD offer confidentiality protection.

   o  The protocol solution SHOULD ensure that operations in default
      configuration guarantees a low number of AN/NAS protocol
      interactions.

   o  The protocol solution SHOULD ensure the access control of the
      management objects and possibly encrypt the values of these
      objects when sending them over the networks.

9.  Security Considerations

   This document focuses on security threats, deriving a threat model
   for ANCP and presenting the security requirements to be considered
   for the design of ANCP.

Moustafa, et al.             Informational                     [Page 16]
RFC 5713                      ANCP Threats                  January 2010

10.  Acknowledgments

   Many thanks go to Francois Le Faucher for reviewing this document and
   for all his useful comments.  The authors would also like to thank
   Philippe Niger, Curtis Sherbo, and Michael Busser for reviewing this
   document.  Other thanks go to Bharat Joshi, Mark Townsley, Wojciech
   Dec, and Kim Hylgaard who have had valuable comments during the
   development of this work.

11.  References

11.1.  Normative References

   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3365]     Schiller, J., "Strong Security Requirements for
                 Internet Engineering Task Force Standard Protocols",
                 BCP 61, RFC 3365, August 2002.

11.2.  Informative References

   [ANCP-FRAME]  Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
                 Wadhwa, "Framework and Requirements for an Access Node
                 Control Mechanism in Broadband  Multi-Service
                 Networks", Work in Progress, October 2009.

   [ANCP-MIB]    De Cnodder, S. and M. Morgenstern, "Access Node Control
                 Protocol (ANCP) MIB module for Access Nodes", Work
                 in Progress, July 2009.

Moustafa, et al.             Informational                     [Page 17]
RFC 5713                      ANCP Threats                  January 2010

Authors' Addresses

   Hassnaa Moustafa
   France Telecom
   38-40 rue du General Leclerc
   Issy Les Moulineaux,   92794 Cedex 9
   France

   EMail: hassnaa.moustafa@orange-ftgroup.com

   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   Phone: +358 (50) 4871445
   EMail: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at

   Stefaan De Cnodder
   Alcatel-Lucent
   Copernicuslaan 50
   B-2018 Antwerp,
   Belgium

   Phone: +32 3 240 85 15
   EMail: stefaan.de_cnodder@alcatel-lucent.com

Moustafa, et al.             Informational                     [Page 18]
Internet-Draft              TCP Specification              November 2017