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.