8.  Security Considerations

   The security requirement for GIST is to protect the signalling plane
   against identified security threats.  For the signalling problem as a
   whole, these threats have been outlined in [30]; the NSIS framework
   [29] assigns a subset of the responsibilities to the NTLP.  The main
   issues to be handled can be summarised as:

   Message Protection:  Signalling message content can be protected
      against eavesdropping, modification, injection, and replay while
      in transit.  This applies to GIST payloads, and GIST should also
      provide such protection as a service to signalling applications
      between adjacent peers.

   Routing State Integrity Protection:  It is important that signalling
      messages are delivered to the correct nodes, and nowhere else.
      Here, 'correct' is defined as 'the appropriate nodes for the
      signalling given the Message-Routing-Information'.  In the case
      where the MRI is based on the flow identification for path-coupled
      signalling, 'appropriate' means 'the same nodes that the
      infrastructure will route data flow packets through'.  GIST has no
      role in deciding whether the data flow itself is being routed
      correctly; all it can do is to ensure that signalling and data
      routing are consistent with each other.  GIST uses internal state
      to decide how to route signalling messages, and this state needs
      to be protected against corruption.

   Prevention of Denial-of-Service Attacks:  GIST nodes and the network
      have finite resources (state storage, processing power,
      bandwidth).  The protocol tries to minimise exhaustion attacks
      against these resources and not allow GIST nodes to be used to
      launch attacks on other network elements.

   The main additional issue is handling authorisation for executing
   signalling operations (e.g., allocating resources).  This is assumed
   to be done in each signalling application.

   In many cases, GIST relies on the security mechanisms available in
   messaging associations to handle these issues, rather than
   introducing new security measures.  Obviously, this requires the
   interaction of these mechanisms with the rest of the GIST protocol to
   be understood and verified, and some aspects of this are discussed in
   Section 5.7.

8.1.  Message Confidentiality and Integrity

   GIST can use messaging association functionality, specifically in
   this version TLS (Section 5.7.3), to ensure message confidentiality
   and integrity.  Implementation of this functionality is REQUIRED but
   its use for any given flow or signalling application is OPTIONAL.  In
   some cases, confidentiality of GIST information itself is not likely
   to be a prime concern, in particular, since messages are often sent
   to parties that are unknown ahead of time, although the content
   visible even at the GIST level gives significant opportunities for
   traffic analysis.  Signalling applications may have their own
   mechanism for securing content as necessary; however, they may find
   it convenient to rely on protection provided by messaging
   associations, since it runs unbroken between signalling application
   peers.

8.2.  Peer Node Authentication

   Cryptographic protection (of confidentiality or integrity) requires a
   security association with session keys.  These can be established by
   an authentication and key exchange protocol based on shared secrets,
   public key techniques, or a combination of both.  Authentication and
   key agreement are possible using the protocols associated with the
   messaging association being secured.  TLS incorporates this
   functionality directly.  GIST nodes rely on the messaging association
   protocol to authenticate the identity of the next hop, and GIST has
   no authentication capability of its own.

   With routing state discovery, there are few effective ways to know
   what is the legitimate next or previous hop as opposed to an
   impostor.  In other words, cryptographic authentication here only

   provides assurance that a node is 'who' it is (i.e., the legitimate
   owner of identity in some namespace), not 'what' it is (i.e., a node
   which is genuinely on the flow path and therefore can carry out
   signalling for a particular flow).  Authentication provides only
   limited protection, in that a known peer is unlikely to lie about its
   role.  Additional methods of protection against this type of attack
   are considered in Section 8.3 below.

   It is an implementation issue whether peer node authentication should
   be made signalling application dependent, for example, whether
   successful authentication could be made dependent on presenting
   credentials related to a particular signalling role (e.g., signalling
   for QoS).  The abstract API of Appendix B leaves open such policy and
   authentication interactions between GIST and the NSLP it is serving.
   However, it does allow applications to inspect the authenticated
   identity of the peer to which a message will be sent before
   transmission.

8.3.  Routing State Integrity

   Internal state in a node (see Section 4.2) is used to route messages.
   If this state is corrupted, signalling messages may be misdirected.

   In the case where the MRM is path-coupled, the messages need to be
   routed identically to the data flow described by the MRI, and the
   routing state table is the GIST view of how these flows are being
   routed through the network in the immediate neighbourhood of the
   node.  Routes are only weakly secured (e.g., there is no
   cryptographic binding of a flow to a route), and there is no
   authoritative information about flow routes other than the current
   state of the network itself.  Therefore, consistency between GIST and
   network routing state has to be ensured by directly interacting with
   the IP routing mechanisms to ensure that the signalling peers are the
   appropriate ones for any given flow.  An overview of security issues
   and techniques in this context is provided in [37].

   In one direction, peer identification is installed and refreshed only
   on receiving a Response (compare Figure 5).  This MUST echo the
   cookie from a previous Query, which will have been sent along the
   flow path with the Q-mode encapsulation, i.e., end-to-end addressed.
   Hence, only the true next peer or an on-path attacker will be able to
   generate such a message, provided freshness of the cookie can be
   checked at the Querying node.

   In the other direction, peer identification MAY be installed directly
   on receiving a Query containing addressing information for the
   signalling source.  However, any node in the network could generate

   such a message; indeed, many nodes in the network could be the
   genuine upstream peer for a given flow.  To protect against this,
   four strategies are used:

   Filtering:  The receiving node MAY reject signalling messages that
      claim to be for flows with flow source addresses that could be
      ruled out by ingress filtering.  An extension of this technique
      would be for the receiving node to monitor the data plane and to
      check explicitly that the flow packets are arriving over the same
      interface and if possible from the same link layer neighbour as
      the D-mode signalling packets.  If they are not, it is likely that
      at least one of the signalling or flow packets is being spoofed.

   Return routability checking:  The receiving node MAY refuse to
      install upstream state until it has completed a Confirm handshake
      with the peer.  This echoes the Responder-Cookie of the Response,
      and discourages nodes from using forged source addresses.  This
      also plays a role in denial-of-service prevention; see below.

   Authorisation:  A stronger approach is to carry out a peer
      authorisation check (see Section 4.4.2) as part of messaging
      association setup.  The ideal situation is that the receiving node
      can determine the correct upstream node address from routing table
      analysis or knowledge of local topology constraints, and then
      verify from the authorised peer database (APD) that the peer has
      this IP address.  This is only technically feasible in a limited
      set of deployment environments.  The APD can also be used to list
      the subsets of nodes that are feasible peers for particular source
      or destination subnets, or to blacklist nodes that have previously
      originated attacks or exist in untrustworthy networks, which
      provide weaker levels of authorisation checking.

   SID segregation:  The routing state lookup for a given MRI and NSLPID
      MUST also take the SID into account.  A malicious node can only
      overwrite existing GIST routing state if it can guess the
      corresponding SID; it can insert state with random SID values, but
      generally this will not be used to route signalling messages for
      which state has already been legitimately established.

8.4.  Denial-of-Service Prevention and Overload Protection

   GIST is designed so that in general each Query only generates at most
   one Response that is at most only slightly larger than the Query, so
   that a GIST node cannot become the source of a denial-of-service
   amplification attack.  (There is a special case of retransmitted
   Response messages; see Section 5.3.3.)

   However, GIST can still be subjected to denial-of-service attacks
   where an attacker using forged source addresses forces a node to
   establish state without return routability, causing a problem similar
   to TCP SYN flood attacks.  Furthermore, an adversary might use
   modified or replayed unprotected signalling messages as part of such
   an attack.  There are two types of state attacks and one
   computational resource attack.  In the first state attack, an
   attacker floods a node with messages that the node has to store until
   it can determine the next hop.  If the destination address is chosen
   so that there is no GIST-capable next hop, the node would accumulate
   messages for several seconds until the discovery retransmission
   attempt times out.  The second type of state-based attack causes GIST
   state to be established by bogus messages.  A related computational/
   network-resource attack uses unverified messages to cause a node
   query an authentication or authorisation infrastructure, or attempt
   to cryptographically verify a digital signature.

   We use a combination of two defences against these attacks:

   1.  The Responding node need not establish a session or discover its
       next hop on receiving the Query, but MAY wait for a Confirm,
       possibly on a secure channel.  If the channel exists, the
       additional delay is one one-way delay and the total is no more
       than the minimal theoretically possible delay of a three-way
       handshake, i.e., 1.5 node-to-node round-trip times.  The delay
       gets significantly larger if a new connection needs to be
       established first.

   2.  The Response to the Query contains a cookie, which is repeated in
       the Confirm.  State is only established for messages that contain
       a valid cookie.  The setup delay is also 1.5 round-trip times.
       This mechanism is similar to that in SCTP [39] and other modern
       protocols.

   There is a potential overload condition if a node is flooded with
   Query or Confirm messages.  One option is for the node to bypass
   these messages altogether as described in Section 4.3.2, effectively
   falling back to being a non-NSIS node.  If this is not possible, a
   node MAY still choose to limit the rate at which it processes Query
   messages and discard the excess, although it SHOULD first adapt its
   policy to one of sending Responses statelessly if it is not already
   doing so.  A conformant GIST node will automatically decrease the
   load by retransmitting Queries with an exponential backoff.  A non-
   conformant node (launching a DoS attack) can generate uncorrelated
   Queries at an arbitrary rate, which makes it hard to apply rate-
   limiting without also affecting genuine handshake attempts.  However,

   if Confirm messages are requested, the cookie binds the message to a
   Querying node address that has been validated by a return routability
   check and rate-limits can be applied per source.

   Once a node has decided to establish routing state, there may still
   be transport and security state to be established between peers.
   This state setup is also vulnerable to denial-of-service attacks.
   GIST relies on the implementations of the lower layer protocols that
   make up messaging associations to mitigate such attacks.  In the
   current specification, the Querying node is always the one wishing to
   establish a messaging association, so it is the Responding node that
   needs to be protected.  It is possible for an attacking node to
   execute these protocols legally to set up large numbers of
   associations that were never used, and Responding node
   implementations MAY use rate-limiting or other techniques to control
   the load in such cases.

   Signalling applications can use the services provided by GIST to
   defend against certain (e.g., flooding) denial-of-service attacks.
   In particular, they can elect to process only messages from peers
   that have passed a return routability check or been authenticated at
   the messaging association level (see Appendix B.2).  Signalling
   applications that accept messages under other circumstances (in
   particular, before routing state has been fully established at the
   GIST level) need to take this into account when designing their
   denial-of-service prevention mechanisms, for example, by not creating
   local state as a result of processing such messages.  Signalling
   applications can also manage overload by invoking flow control, as
   described in Section 4.1.1.

8.5.  Requirements on Cookie Mechanisms

   The requirements on the Query-Cookie can be summarised as follows:

   Liveness:  The cookie must be live; that is, it must change from one
      handshake to the next.  This prevents replay attacks.

   Unpredictability:  The cookie must not be guessable, e.g., from a
      sequence or timestamp.  This prevents direct forgery after
      capturing a set of earlier messages.

   Easily validated:  It must be efficient for the Q-Node to validate
      that a particular cookie matches an in-progress handshake, for a
      routing state machine that already exists.  This allows to discard
      responses that have been randomly generated by an adversary, or to
      discard responses to queries that were generated with forged
      source addresses or an incorrect address in the included NLI
      object.

   Uniqueness:  Each handshake must have a unique cookie since the
      cookie is used to match responses within a handshake, e.g., when
      multiple messaging associations are multiplexed over the same
      transport connection.

   Likewise, the requirements on the Responder-Cookie can be summarised
   as follows:

   Liveness:  The cookie must be live as above, to prevent replay
      attacks.

   Creation simplicity:  The cookie must be lightweight to generate in
      order to avoid resource exhaustion at the responding node.

   Validation simplicity:  It must be simple for the R-node to validate
      that an R-Cookie was generated by itself and no one else, without
      storing state about the handshake for which it was generated.

   Binding:  The cookie must be bound to the routing state that will be
      installed, to prevent use with different routing state, e.g., in a
      modified Confirm.  The routing state here includes the Peer-
      Identity and Interface-Address given in the NLI of the Query, and
      the MRI/NSLPID for the messaging.

      It can also include the interface on which the Query was received
      for use later in route change detection (Section 7.1.2).  Since a
      Q-mode encapsulated message is the one that will best follow the
      data path, subsequent changes in this arrival interface indicate
      route changes between the peers.

   A suitable implementation for the Q-Cookie is a cryptographically
   strong random number that is unique for this routing state machine
   handshake.  A node MUST implement this or an equivalently strong
   mechanism.  Guidance on random number generation can be found in
   [31].

   A suitable basic implementation for the R-Cookie is as follows:

        R-Cookie = liveness data + reception interface
                   + hash (locally known secret,
                           Q-Node NLI identity and address, MRI, NSLPID,
                           liveness data)

   A node MUST implement this or an equivalently strong mechanism.
   There are several alternatives for the liveness data.  One is to use
   a timestamp like SCTP.  Another is to give the local secret a (rapid)
   rollover, with the liveness data as the generation number of the
   secret, like IKEv2.  In both cases, the liveness data has to be

   carried outside the hash, to allow the hash to be verified at the
   Responder.  Another approach is to replace the hash with encryption
   under a locally known secret, in which case the liveness data does
   not need to be carried in the clear.  Any symmetric cipher immune to
   known plaintext attacks can be used.  In the case of GIST-aware NAT
   traversal with delayed state installation, it is necessary to carry
   additional data in the cookie; appropriate constructions are
   described in [44].

   To support the validation simplicity requirement, the Responder can
   check the liveness data to filter out some blind (flooding) attacks
   before beginning any cryptographic cookie verification.  To support
   this usage, the liveness data must be carried in the clear and not be
   easily guessable; this rules out the timestamp approach and suggests
   the use of sequence of secrets with the liveness data identifying the
   position in the sequence.  The secret strength and rollover frequency
   must be high enough that the secret cannot be brute-forced during its
   lifetime.  Note that any node can use a Query to discover the current
   liveness data, so it remains hard to defend against sophisticated
   attacks that disguise such probes within a flood of Queries from
   forged source addresses.  Therefore, it remains important to use an
   efficient hashing mechanism or equivalent.

   If a node receives a message for which cookie validation fails, it
   MAY return an "Object Value Error" message (Appendix A.4.4.10) with
   subcode 4 ("Invalid Cookie") to the sender and SHOULD log an error
   condition locally, as well as dropping the message.  However, sending
   the error in general makes a node a source of backscatter.
   Therefore, this MUST only be enabled selectively, e.g., during
   initial deployment or debugging.

8.6.  Security Protocol Selection Policy

   This specification defines a single mandatory-to-implement security
   protocol (TLS; Section 5.7.3).  However, it is possible to define
   additional security protocols in the future, for example, to allow
   re-use with other types of credentials, or migrate towards protocols
   with stronger security properties.  In addition, use of any security
   protocol for a messaging association is optional.  Security protocol
   selection is carried out as part of the GIST handshake mechanism
   (Section 4.4.1).

   The selection process may be vulnerable to downgrade attacks, where a
   man in the middle modifies the capabilities offered in the Query or
   Response to mislead the peers into accepting a lower level of
   protection than is achievable.  There is a two-part defence against
   such attacks (the following is based the same concepts as [25]):

   1.  The Response does not depend on the Stack-Proposal in the Query
       (see Section 5.7.1).  Therefore, tampering with the Query has no
       effect on the resulting messaging association configuration.

   2.  The Responding node's Stack-Proposal is echoed in the Confirm.
       The Responding node checks this to validate that the proposal it
       made in the Response is the same as the one received by the
       Querying node.  Note that as a consequence of the previous point,
       the Responding node does not have to remember the proposal
       explicitly, since it is a static function of local policy.

   The validity of the second part depends on the strength of the
   security protection provided for the Confirm.  If the Querying node
   is prepared to create messaging associations with null security
   properties (e.g., TCP only), the defence is ineffective, since the
   man in the middle can re-insert the original Responder's Stack-
   Proposal, and the Responding node will assume that the minimal
   protection is a consequence of Querying node limitations.  However,
   if the messaging association provides at least integrity protection
   that cannot be broken in real-time, the Confirm cannot be modified in
   this way.  Therefore, if the Querying node does not apply a security
   policy to the messaging association protocols to be created that
   ensures at least this minimal level of protection is met, it remains
   open to the threat that a downgrade has occurred.  Applying such a
   policy ensures capability discovery process will result in the setup
   of a messaging association with the correct security properties for
   the two peers involved.

8.7.  Residual Threats

   Taking the above security mechanisms into account, the main residual
   threats against NSIS are three types of on-path attack,
   vulnerabilities from particular limited modes of TLS usage, and
   implementation-related weaknesses.

   An on-path attacker who can intercept the initial Query can do most
   things it wants to the subsequent signalling.  It is very hard to
   protect against this at the GIST level; the only defence is to use
   strong messaging association security to see whether the Responding
   node is authorised to take part in NSLP signalling exchanges.  To
   some extent, this behaviour is logically indistinguishable from
   correct operation, so it is easy to see why defence is difficult.
   Note that an on-path attacker of this sort can do anything to the
   traffic as well as the signalling.  Therefore, the additional threat
   induced by the signalling weakness seems tolerable.

   At the NSLP level, there is a concern about transitivity of trust of
   correctness of routing along the signalling chain.  The NSLP at the
   querying node can have good assurance that it is communicating with
   an on-path peer or a node delegated by the on-path node by depending
   on the security protection provided by GIST.  However, it has no
   assurance that the node beyond the responder is also on-path, or that
   the MRI (in particular) is not being modified by the responder to
   refer to a different flow.  Therefore, if it sends signalling
   messages with payloads (e.g., authorisation tokens) that are valuable
   to nodes beyond the adjacent hop, it is up to the NSLP to ensure that
   the appropriate chain of trust exists.  This could be achieved using
   higher layer security protection such as Cryptographic Message Syntax
   (CMS) [28].

   There is a further residual attack by a node that is not on the path
   of the Query, but is on the path of the Response, or is able to use a
   Response from one handshake to interfere with another.  The attacker
   modifies the Response to cause the Querying node to form an adjacency
   with it rather than the true peer.  In principle, this attack could
   be prevented by including an additional cryptographic object in the
   Response that ties the Response to the initial Query and the routing
   state and can be verified by the Querying node.

   GIST depends on TLS for peer node authentication, and subsequent
   channel security.  The analysis in [30] indicates the threats that
   arise when the peer node authentication is incomplete --
   specifically, when unilateral authentication is performed (one node
   authenticates the other, but not vice versa).  In this specification,
   mutual authentication can be supported either by certificate exchange
   or the use of pre-shared keys (see Section 5.7.3); if some other TLS
   authentication mechanism is negotiated, its properties would have to
   be analysed to determine acceptability for use with GIST.  If mutual
   authentication is performed, the requirements for NTLP security are
   met.

   However, in the case of certificate exchange, this specification
   allows the possibility that only a server certificate is provided,
   which means that the Querying node authenticates the Responding node
   but not vice versa.  Accepting such unilateral authentication allows
   for partial security in environments where client certificates are
   not widespread, and is better than no security at all; however, it
   does expose the Responding node to certain threats described in
   Section 3.1 of [30].  For example, the Responding node cannot verify
   whether there is a man-in-the-middle between it and the Querying
   node, which could be manipulating the signalling messages, and it
   cannot verify the identity of the Querying node if it requests
   authorisation of resources.  Note that in the case of host-network
   signalling, the Responding node could be either the host or the first

   hop router, depending on the signalling direction.  Because of these
   vulnerabilities, modes or deployments of TLS which do not provide
   mutual authentication can be considered as at best transitional
   stages rather than providing a robust security solution.

   Certain security aspects of GIST operation depend on signalling
   application behaviour: a poorly implemented or compromised NSLP could
   degrade GIST security.  However, the degradation would only affect
   GIST handling of the NSLP's own signalling traffic or overall
   resource usage at the node where the weakness occurred, and
   implementation weakness or compromise could have just as great an
   effect within the NSLP itself.  GIST depends on NSLPs to choose SIDs
   appropriately (Section 4.1.3).  If NSLPs choose non-random SIDs, this
   makes off-path attacks based on SID guessing easier to carry out.
   NSLPs can also leak information in structured SIDs, but they could
   leak similar information in the NSLP payload data anyway.

9.  IANA Considerations

   This section defines the registries and initial codepoint assignments
   for GIST.  It also defines the procedural requirements to be followed
   by IANA in allocating new codepoints.  Note that the guidelines on
   the technical criteria to be followed in evaluating requests for new
   codepoint assignments are covered normatively in a separate document
   that considers the NSIS protocol suite in a unified way.  That
   document discusses the general issue of NSIS extensibility, as well
   as the technical criteria for particular registries; see [12] for
   further details.

   The registry definitions that follow leave large blocks of codes
   marked "Reserved".  This is to allow a future revision of this
   specification or another Experimental document to modify the relative
   space given to different allocation policies, without having to
   change the initial rules retrospectively if they turn out to have
   been inappropriate, e.g., if the space for one particular policy is
   exhausted too quickly.

   The allocation policies used in this section follow the guidance
   given in [4].  In addition, for a number of the GIST registries, this
   specification also defines private/experimental ranges as discussed
   in [9].  Note that the only environment in which these codepoints can
   validly be used is a closed one in which the experimenter knows all
   the experiments in progress.

   This specification allocates the following codepoints in existing
   registries:

      Well-known UDP port 270 as the destination port for Q-mode
      encapsulated GIST messages (Section 5.3).

   This specification creates the following registries with the
   structures as defined below:

   NSLP Identifiers:  Each signalling application requires the
      assignment of one or more NSLPIDs.  The following NSLPID is
      allocated by this specification:

   +---------+---------------------------------------------------------+
   | NSLPID  | Application                                             |
   +---------+---------------------------------------------------------+
   | 0       | Used for GIST messages not related to any signalling    |
   |         | application.                                            |
   +---------+---------------------------------------------------------+

      Every other NSLPID that uses an MRM that requires RAO usage MUST
      be associated with a specific RAO value; multiple NSLPIDs MAY be
      associated with the same RAO value.  RAO value assignments require
      a specification of the processing associated with messages that
      carry the value.  NSLP specifications MUST normatively depend on
      this document for the processing, specifically Sections 4.3.1,
      4.3.4 and 5.3.2.  The NSLPID is a 16-bit integer, and the
      registration procedure is IESG Aproval.  Further values are as
      follows:

      1-32703:  Unassigned

      32704-32767:  Private/Experimental Use

      32768-65536:  Reserved

   GIST Message Type:  The GIST common header (Appendix A.1) contains a
      7-bit message type field.  The following values are allocated by
      this specification:

                          +---------+----------+
                          | MType   | Message  |
                          +---------+----------+
                          | 0       | Query    |
                          |         |          |
                          | 1       | Response |
                          |         |          |
                          | 2       | Confirm  |
                          |         |          |
                          | 3       | Data     |
                          |         |          |
                          | 4       | Error    |
                          |         |          |
                          | 5       | MA-Hello |
                          +---------+----------+

      Registration procedures are as follows:

      0-31:  IETF Review

      32-55:  Expert Review

      Further values are as follows:

      6-55:  Unassigned

      56-63:  Private/Experimental Use

      64-127:  Reserved

   Object Types:  There is a 12-bit field in the object header
      (Appendix A.2).  The following values for object type are defined
      by this specification:

                 +---------+-----------------------------+
                 | OType   | Object Type                 |
                 +---------+-----------------------------+
                 | 0       | Message Routing Information |
                 |         |                             |
                 | 1       | Session ID                  |
                 |         |                             |
                 | 2       | Network Layer Information   |
                 |         |                             |
                 | 3       | Stack Proposal              |
                 |         |                             |
                 | 4       | Stack Configuration Data    |
                 |         |                             |
                 | 5       | Query-Cookie                |
                 |         |                             |
                 | 6       | Responder-Cookie            |
                 |         |                             |
                 | 7       | NAT Traversal               |
                 |         |                             |
                 | 8       | NSLP Data                   |
                 |         |                             |
                 | 9       | Error                       |
                 |         |                             |
                 | 10      | Hello ID                    |
                 +---------+-----------------------------+

      Registration procedures are as follows:

      0-1023:  IETF Review

      1024-1999:  Specification Required

      Further values are as follows:

      11-1999:  Unassigned

      2000-2047:  Private/Experimental Use

      2048-4095:  Reserved

      When a new object type is allocated according to one of the
      procedures, the specification MUST provide the object format and
      define the setting of the extensibility bits (A/B; see
      Appendix A.2.1).

   Message Routing Methods:  GIST allows multiple message routing
      methods (see Section 3.3).  The MRM is indicated in the leading
      byte of the MRI object (Appendix A.3.1).  This specification
      defines the following values:

                  +------------+------------------------+
                  | MRM-ID     | Message Routing Method |
                  +------------+------------------------+
                  | 0          | Path-Coupled MRM       |
                  |            |                        |
                  | 1          | Loose-End MRM          |
                  +------------+------------------------+

      Registration procedures are as follows:

      0-63:  IETF Review

      64-119:  Specification Required

      Further values are as follows:

      2-119:  Unassigned

      120-127:  Private/Experimental Use

      128-255:  Reserved

      When a new MRM is allocated according to one of the registration
      procedures, the specification MUST provide the information
      described in Section 3.3.

   MA-Protocol-IDs:  Each protocol that can be used in a messaging
      association is identified by a 1-byte MA-Protocol-ID
      (Section 5.7).  Note that the MA-Protocol-ID is not an IP protocol
      number; indeed, some of the messaging association protocols --
      such as TLS -- do not have an IP protocol number.  This is used as
      a tag in the Stack-Proposal and Stack-Configuration-Data objects
      (Appendix A.3.4 and Appendix A.3.5).  The following values are
      defined by this specification:

     +---------------------+-----------------------------------------+
     | MA-Protocol-ID      | Protocol                                |
     +---------------------+-----------------------------------------+
     | 0                   | Reserved                                |
     |                     |                                         |
     | 1                   | TCP opened in the forwards direction    |
     |                     |                                         |
     | 2                   | TLS initiated in the forwards direction |
     +---------------------+-----------------------------------------+

      Registration procedures are as follows:

      0-63:  IETF Review

      64-119:  Expert Review

      Further values are as follows:

      3-119:  Unassigned

      120-127:  Private/Experimental Use

      128-255:  Reserved

      When a new MA-Protocol-ID is allocated according to one of the
      registration procedures, a specification document will be
      required.  This MUST define the format for the MA-protocol-options
      field (if any) in the Stack-Configuration-Data object that is
      needed to define its configuration.  If a protocol is to be used
      for reliable message transfer, it MUST be described how delivery
      errors are to be detected by GIST.  Extensions to include new
      channel security protocols MUST include a description of how to
      integrate the functionality described in Section 3.9 with the rest
      of GIST operation.  If the new MA-Protocol-ID can be used in
      conjunction with existing ones (for example, a new transport
      protocol that could be used with Transport Layer Security), the
      specification MUST define the interaction between the two.

   Error Codes/Subcodes:  There is a 2-byte error code and 1-byte
      subcode in the Value field of the Error Object (Appendix A.4.1).
      Error codes 1-12 are defined in Appendix A.4.4 together with
      subcodes 0-5 (code 1), 0-5 (code 9), 0-5 (code 10), and 0-2 (code
      12).  Additional codes and subcodes are allocated on a first-come,
      first-served basis.  When a new code/subcode combination is
      allocated, the following information MUST be provided:

      Error case:  textual name of error

      Error class:  from the categories given in Appendix A.4.3

      Error code:  allocated by IANA, if a new code is required

      Error subcode:  subcode point, also allocated by IANA

      Additional information:  what Additional Information fields are
         mandatory to include in the error message, from Appendix A.4.2

   Additional Information Types:  An Error Object (Appendix A.4.1) may
      contain Additional Information fields.  Each possible field type
      is identified by a 16-bit AI-Type.  AI-Types 1-4 are defined in
      Appendix A.4.2; additional AI-Types are allocated on a first-come,
      first-served basis.

10.  Acknowledgements

   This document is based on the discussions within the IETF NSIS
   working group.  It has been informed by prior work and formal and
   informal inputs from: Cedric Aoun, Attila Bader, Vitor Bernado,
   Roland Bless, Bob Braden, Marcus Brunner, Benoit Campedel, Yoshiko
   Chong, Luis Cordeiro, Elwyn Davies, Michel Diaz, Christian Dickmann,
   Pasi Eronen, Alan Ford, Xiaoming Fu, Bo Gao, Ruediger Geib, Eleanor
   Hepworth, Thomas Herzog, Cheng Hong, Teemu Huovila, Jia Jia, Cornelia
   Kappler, Georgios Karagiannis, Ruud Klaver, Max Laier, Chris Lang,
   Lauri Liuhto, John Loughney, Allison Mankin, Jukka Manner, Pete
   McCann, Andrew McDonald, Mac McTiffin, Glenn Morrow, Dave Oran,
   Andreas Pashalidis, Henning Peters, Tom Phelan, Akbar Rahman, Takako
   Sanda, Charles Shen, Melinda Shore, Martin Stiemerling, Martijn
   Swanink, Mike Thomas, Hannes Tschofenig, Sven van den Bosch, Nuutti
   Varis, Michael Welzl, Lars Westberg, and Mayi Zoumaro-djayoon.  Parts
   of the TLS usage description (Section 5.7.3) were derived from the
   Diameter base protocol specification, RFC 3588.  In addition, Hannes
   Tschofenig provided a detailed set of review comments on the security
   section, and Andrew McDonald provided the formal description for the
   initial packet formats and the name matching algorithm for TLS.
   Chris Lang's implementation work provided objective feedback on the
   clarity and feasibility of the specification, and he also provided
   the state machine description and the initial error catalogue and
   formats.  Magnus Westerlund carried out a detailed AD review that
   identified a number of issues and led to significant clarifications,
   which was followed by an even more detailed IESG review, with
   comments from Jari Arkko, Ross Callon, Brian Carpenter, Lisa
   Dusseault, Lars Eggert, Ted Hardie, Sam Hartman, Russ Housley, Cullen

   Jennings, and Tim Polk, and a very detailed analysis by Adrian Farrel
   from the Routing Area directorate; Suresh Krishnan carried out a
   detailed review for the Gen-ART.

11.  References

11.1.  Normative References

   [1]   Braden, R., "Requirements for Internet Hosts - Communication
         Layers", STD 3, RFC 1122, October 1989.

   [2]   Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
         June 1995.

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

   [4]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

   [5]   Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
         Specification", RFC 2460, December 1998.

   [6]   Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
         the Differentiated Services Field (DS Field) in the IPv4 and
         IPv6 Headers", RFC 2474, December 1998.

   [7]   Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
         RFC 2765, February 2000.

   [8]   Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley,
         R., and W. Polk, "Internet X.509 Public Key Infrastructure
         Certificate and Certificate Revocation List (CRL) Profile",
         RFC 5280, May 2008.

   [9]   Narten, T., "Assigning Experimental and Testing Numbers
         Considered Useful", BCP 82, RFC 3692, January 2004.

   [10]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
         Protocol Version 1.2", RFC 5246, August 2008.

   [11]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [12]  Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and
         Extending the NSIS Protocol Family", RFC 5978, October 2010.

11.2.  Informative References

   [13]  Katz, D., "IP Router Alert Option", RFC 2113, February 1997.

   [14]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
         "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
         Specification", RFC 2205, September 1997.

   [15]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
         RFC 2246, January 1999.

   [16]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [17]  Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
         RFC 2711, October 1999.

   [18]  Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
         Operation Over IP Tunnels", RFC 2746, January 2000.

   [19]  Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
         IPv4 Clouds", RFC 3056, February 2001.

   [20]  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
         RFC 3068, June 2001.

   [21]  Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
         "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
         September 2001.

   [22]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and
         G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
         RFC 3209, December 2001.

   [23]  Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L.,
         Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M.,
         Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-
         Based LSP Setup using LDP", RFC 3212, January 2002.

   [24]  Grossman, D., "New Terminology and Clarifications for
         Diffserv", RFC 3260, April 2002.

   [25]  Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T.
         Haukka, "Security Mechanism Agreement for the Session
         Initiation Protocol (SIP)", RFC 3329, January 2003.

   [26]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session
         Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.

   [27]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
         Relays around NAT (TURN): Relay Extensions to Session Traversal
         Utilities for NAT (STUN)", RFC 5766, April 2010.

   [28]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC
         5652, September 2009.

   [29]  Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
         Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,
         June 2005.

   [30]  Tschofenig, H. and D. Kroeselberg, "Security Threats for Next
         Steps in Signaling (NSIS)", RFC 4081, June 2005.

   [31]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
         Requirements for Security", BCP 106, RFC 4086, June 2005.

   [32]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for
         Transport Layer Security (TLS)", RFC 4279, December 2005.

   [33]  Conta, A., Deering, S., and M. Gupta, "Internet Control Message
         Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
         Specification", RFC 4443, March 2006.

   [34]  Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/
         Firewall NSIS Signaling Layer Protocol (NSLP)", Work
         in Progress, April 2010.

   [35]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
         IPv6 Hosts and Routers", RFC 4213, October 2005.

   [36]  Kent, S. and K. Seo, "Security Architecture for the Internet
         Protocol", RFC 4301, December 2005.

   [37]  Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
         Nordmark, "Mobile IP Version 6 Route Optimization Security
         Design Background", RFC 4225, December 2005.

   [38]  Audet, F. and C. Jennings, "Network Address Translation (NAT)
         Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787,
         January 2007.

   [39]  Stewart, R., "Stream Control Transmission Protocol", RFC 4960,
         September 2007.

   [40]  Aoun, C. and E. Davies, "Reasons to Move the Network Address
         Translator - Protocol Translator (NAT-PT) to Historic Status",
         RFC 4966, July 2007.

   [41]  Gill, V., Heasley, J., Meyer, D., Savola, P., and C. Pignataro,
         "The Generalized TTL Security Mechanism (GTSM)", RFC 5082,
         October 2007.

   [42]  Floyd, S. and V. Jacobson, "The Synchronisation of Periodic
         Routing Messages", SIGCOMM Symposium on Communications
         Architectures and Protocols pp. 33--44, September 1993.

   [43]  Pashalidis, A. and H. Tschofenig, "GIST Legacy NAT Traversal",
         Work in Progress, July 2007.

   [44]  Pashalidis, A. and H. Tschofenig, "GIST NAT Traversal", Work
         in Progress, July 2007.

   [45]  Tsenov, T., Tschofenig, H., Fu, X., Aoun, C., and E. Davies,
         "GIST State Machine", Work in Progress, April 2010.

   [46]  Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
         Robustness to Blind In-Window Attacks", Work in Progress,
         May 2010.