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
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.
