One document matched: draft-mcdonald-nsis-ntlp-considerations-00.txt
Network Working Group A. McDonald
Internet-Draft R. Hancock
Expires: July 24, 2003 E. Hepworth
Siemens/Roke Manor Research
January 23, 2003
Design Considerations for an NSIS Transport Layer Protocol
draft-mcdonald-nsis-ntlp-considerations-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 24, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
A framework for NSIS is in preparation, and will identify a split
into two layers. The lower layer, referred to as the NSIS Transport
Layer Protocol (NTLP) provides generic support for different types of
path coupled signalling, including QoS signalling. This document
discusses issues to be considered in the design of an NSIS Transport
Layer Protocol (NTLP).
McDonald, et al. Expires July 24, 2003 [Page 1]
Internet-Draft NTLP Design Considerations January 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Transport Functionality Issues . . . . . . . . . . . . . . . 3
2.1 Congestion Avoidance . . . . . . . . . . . . . . . . . . . . 4
2.2 Message Bundling . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Message vs. Stream based transports . . . . . . . . . . . . 5
2.4 Message fragmentation . . . . . . . . . . . . . . . . . . . 5
2.5 Message reordering and Head of line blocking . . . . . . . . 6
2.6 Duplicate Message Detection . . . . . . . . . . . . . . . . 6
2.7 Lossless Transport and Loss Detection . . . . . . . . . . . 6
2.8 Other Issues . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Routing and Discovery . . . . . . . . . . . . . . . . . . . 7
3.1 Peer Discovery . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Path Discovery . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Capability Discovery . . . . . . . . . . . . . . . . . . . . 8
3.4 Path Divergence . . . . . . . . . . . . . . . . . . . . . . 8
3.4.1 Signalling/Data Path Divergence . . . . . . . . . . . . . . 8
3.4.2 Path Divergence Through Rerouting . . . . . . . . . . . . . 9
4. NAT and Firewall Traversal . . . . . . . . . . . . . . . . . 10
5. State Location . . . . . . . . . . . . . . . . . . . . . . . 10
6. Overload Protection . . . . . . . . . . . . . . . . . . . . 12
7. Failure detection and Failover . . . . . . . . . . . . . . . 12
8. Feedback/Error Messages . . . . . . . . . . . . . . . . . . 12
9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1 Message Protection . . . . . . . . . . . . . . . . . . . . . 14
9.2 Denial of Service Protection . . . . . . . . . . . . . . . . 14
10. Message Objects and Extensibility . . . . . . . . . . . . . 14
11. Other Functionality . . . . . . . . . . . . . . . . . . . . 15
11.1 Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.2 Inter/Intra Domain Use . . . . . . . . . . . . . . . . . . . 15
11.3 Mobility Support . . . . . . . . . . . . . . . . . . . . . . 15
11.4 Session/State Identification . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . 15
Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
McDonald, et al. Expires July 24, 2003 [Page 2]
Internet-Draft NTLP Design Considerations January 2003
1. Introduction
This document assumes the framework as discussed in [1]. In
particular, the NSIS framework defines high level issues of how the
NTLP overall interacts with other protocols (e.g. routing and
mobility issues) and how it is used to support signalling
applications, and defines the overall functionality that the NTLP
should support. (The precise functionality required of the NTLP has
not been finally defined, and might be impacted by some of the design
considerations given here. It is always possible to argue that a
particular design question is irrelevant since the corresponding
function is not necessary in the first place.) The focus for this
document is primarily internal aspects of the NTLP design, although
these can be strongly influenced by usage scenarios (especially in
performance aspects). Overall requirements for signalling protocols
are given in [2].
The original proposal for a split layer signalling protocol has been
given in [9], which also contains extensive discussion of the design
rationale for CSTP, which is the proposed NTLP there. There are
additional proposals for the NTLP with accompanying design rationale,
e.g. CASP [11] and direct re-use of RSVP [12].
The purpose of this document is not to analyse all the design options
and fix a particular approach for the NTLP, but initially simply to
consolidate the questions and issues that have to be considered.
The pattern for the sections in this document is something like:
o Identify issues that the NTLP must address
o Identify some of the applicable techniques and their implications
o Illustrate how these techniques relate to using existing protocols
(especially the case of RSVP)
2. Transport Functionality Issues
This section considers 'traditional' transport layer functions such
as reliability, congestion management and so on. In the NSIS protocol
suite, these functions are primarily the responsibility of the NTLP.
One overall question when considering transport layer issues is:
should we use an already existing, standard transport protocol (e.g.
TCP or SCTP) or not?
Do different parts of the NTLP behaviour have different requirements?
McDonald, et al. Expires July 24, 2003 [Page 3]
Internet-Draft NTLP Design Considerations January 2003
And, consequently do different parts of the NTLP require different
choices to be made about whether to use a standard or custom
transport protocol?
Usability of existing transport layers for AAA traffic is analysed in
[14] and some of the same issues may be relevant here.
A significant issue for deciding what transport functionality the
NTLP should provide is that communication between NSLP peers might be
performed over a single NTLP hop, or a series of concatenated NTLP
hops (if there are intervening NSIS entities which do not process the
relevant signalling application). In the former case, rigorous
end-to-end thinking pushes more functionality out of the NTLP and
into the NSLP.
2.1 Congestion Avoidance
The NTLP must provide congestion control mechanisms (e.g. as
described in [6]). This might be provided in a specialised way as
part of a custom protocol directly over IP. Alternatively, an
existing protocol which already provides congestion control, such as
TCP or SCTP might be used to carry NTLP.
The base RSVP protocol contains no congestion control mechanism.
Exponential back-off procedures for RSVP are described in section 6
of RFC2961 [7].
If using TCP or SCTP, will the standard transport parameter
estimation algorithms function correctly? More generally, does
signalling have specialised requirements for congestion handling (and
if it does, is it signalling application specific? - in which case,
should this reside in the NSLP rather than the NTLP?)
2.2 Message Bundling
There are two aspects to the possible provision of bundling in
relation to the NTLP. Should a single NTLP PDU be able to carry
multiple NSLP PDUs (including from different, possibly unrelated,
signalling applications)? Should it be possible to bundle multiple
NTLP PDUs into a single IP datagram (or TCP segment, or SCTP chunk)?
Note that unless bundling is done only for messages relating to flows
between the same endpoints (which would be a very restrictive case),
bundling almost necessarily involves direct ('peer-to-peer')
addressing and hence means additional consideration must be given to
prevention of path divergence (see Section 3.4).
In order to reduce the per signalling PDU overhead, a message
bundling mechanism is provided within RSVP [7]. Because of the
McDonald, et al. Expires July 24, 2003 [Page 4]
Internet-Draft NTLP Design Considerations January 2003
divergence issue, the restriction is made that they can only be used
between direct RSVP neighbours, in order to avoid unnoticed path
divergence as described in Section 3.4. (This suggests the need for
an explicit discovery of whether the next node is a direct
neighbour.) How likely is it that NSLP peers will be direct NTLP
peers (as compared to being separated by more than one NTLP 'hop')?
If an existing transport protocol is used under the NTLP, then
message bundling may exist as part of that protocol. Both TCP and
SCTP support the use of Nagle's algorithm [3] (or a similar
technique), which allows pieces of data from higher layers to be
'bundled' into a single IP packet. Is such a technique appropriate
for NSIS messages? (In particular, are the timing rules implicit in
these algorithms appropriate for signalling messages?)
2.3 Message vs. Stream based transports
The NTLP is message orientated by nature. If it is carried over a
stream-based transport such as TCP then the NTLP needs to be able to
split it out back into individual messages. If a datagram or
message-based transport (such as SCTP, IP or UDP) is used then this
provides the necessary message framing already.
The separate issue of upper layer multiplexing is covered in Section
10.
2.4 Message fragmentation
The NTLP must be capable of performing message fragmentation when the
amount of data in a message to be sent is larger than can fit into a
single IP packet (or a single sensibly-sized IP packet). This may
occur, for example, where certificates are carried in order to
support authentication functions, and also in order to support
features of future NSLPs.
IP fragmentation might be used to provide the NTLP message
fragmentation. In this case the protocol must perform Path MTU
Discovery for IPv6 and should support it for IPv4. (If end-to-end
addressing was used, it is not clear that Path MTU discovery would
function correctly, e.g. if an NSIS entity which was not one of the
flow endpoints needed to perform it.) IP fragmentation is only
supported end-to-end in IPv6.
If TCP or SCTP is used to carry NTLP messages, then fragmentation/
segmentation is provided by these protocols, and PMTU-D can be
expected to be supported as standard.
McDonald, et al. Expires July 24, 2003 [Page 5]
Internet-Draft NTLP Design Considerations January 2003
2.5 Message reordering and Head of line blocking
Can messages arrive out-of-order at the NTLP from lower layers (e.g.
if the NTLP is carried directly over IP or UDP)? If so, does it
matter at the NTLP? Does the NTLP need to be able to re-order the
messages correctly?
Does the NTLP have to guarantee to pass messages in order to the
local NSLP? Or, should it be left to the NSLP to decide whether to
process, re-order or drop messages? How generic to signalling
applications is the requirement for in-order delivery?
In addition, would head-of-line blocking be a problem for the NSIS
protocols?
TCP could used to carry NTLP messages. One way to use it would be to
have a single TCP connection between each pair of NSIS peers, but
this would result in head-of-line blocking (across multiple
signalling sessions). Could more than one TCP connection be used to
mitigate this?
SCTP is another alternative for carrying NTLP messages. SCTP supports
multiple streams within an association. SCTP also supports reliable
delivery of out of order delivery of messages (though this feature is
unavailable when TLS is being used).
In the base RSVP protocol there are no sequence numbers in the
messages. Consequently there is no method to detect out-of-order
delivery or duplicate messages. Out-of-order delivery can still be
allowed when the RSVP Cryptographic Authentication mechanism [5] is
used, although replay protection is provided.
2.6 Duplicate Message Detection
Do we care about receiving duplicate messages at the NTLP, or is this
purely an NSLP problem?
Are security concerns about message replay addressed? (see Section
9).
2.7 Lossless Transport and Loss Detection
How is identification of message loss and/or retransmission provided?
Should the NTLP actually provide true lossless transport end-to-end,
or simply local recovery (peer-to-peer) from messages which can be
detected to have been dropped (e.g. because of congestion)?
McDonald, et al. Expires July 24, 2003 [Page 6]
Internet-Draft NTLP Design Considerations January 2003
2.8 Other Issues
It may be useful for lower layer information to be visible at the
NTLP. For example, changes in the TTL of received packets may be an
indication that a route change has occurred, or the TTL may need to
be controlled explicitly. Given existing implementation constraints,
does this have implications for what encapsulation should be used
(e.g. does it imply the use of raw IP sockets)?
3. Routing and Discovery
3.1 Peer Discovery
Addressing of NTLP messages can be peer-to-peer or end-to-end, as
discussed in section 3.3.4 of [1].
Peer discovery in the data receiver to sender direction is not
required (see the sender/receiver oriented issues discussed in [10]).
In the downstream direction, the NTLP is required to perform peer
discovery (at least implicitly), in addition to transporting NSLP
messages along the data path. Are the messages for discovery
integrated into the rest of the NTLP protocol? Or, is the discovery
mechanism separated from the transport of NSLP messages, for example,
as a dedicated message exchange? Should the NTLP be able to accept
alternative source of information about which peer to talk to?
For the discovery mechanism, how similar are the signalling and data
messages? (see discussion in Section 3.4).
Some NTLP entities also terminate the signalling transport (e.g. when
acting as a proxy on behalf of an end-system). How do you detect that
you are the last NTLP entity before the data receiver? What if there
are more NTLP entities, but none with the relevant NSLP?
RSVP uses end-to-end addressing in some of its messages, and makes
use of the IPv4 router alert option (or IPv6 hop-by-hop option) to
inform routers that they should intercept and process the messages.
Further details are discussed in section 4.1 of [1].
3.2 Path Discovery
The NTLP does not provide an explicit topology or path discovery
service to the NSLP. It does, however, carry out implicit path
discovery simply by being able to route from one NTLP hop to the
next.
Is the state necessary for backwards routing stored locally at each
McDonald, et al. Expires July 24, 2003 [Page 7]
Internet-Draft NTLP Design Considerations January 2003
node, or carried in route record objects (see further discussion in
Section 5).
3.3 Capability Discovery
The NTLP needs to consider Capability Discovery and/or Exchange and/
or Agreement. What sort of things appear as "capabilities"? -
signalling applications (i.e. NSLPs), types of signalling
application, supported features, options, etc?
RSVP can use AdSpec objects to learn information from nodes along a
path primarily for QoS purposes, although the same mechanism could be
generalised for other purposes. There is no mechanism for learning
about the capabilities, security mechanism, supported security
options, identity, etc of peers.
What is the split between the NTLP and NSLPs for capability discovery
mechanisms? What form do the "capabilities" take?
3.4 Path Divergence
Two forms of path divergence must be considered. Firstly, path
divergence may occur when NSIS signalling is sent down a different
route to the main data flow, for example due to policy forwarding
being used to select the route for the data flow. Secondly, path
divergence may occur during the life of a reservation when rerouting
occurs, with the data flow going down a new path, but signalling
state persisting on the old path, and possibly signalling messages
continuing to use the old path.
3.4.1 Signalling/Data Path Divergence
Divergence may occur when policy forwarding is used which takes
account of protocol, transport layer ports, DSCP, etc. in determining
the route for packets. This is of most concern when the initial
signalling connections are being established, but is also of
relevance when rerouting of the data flow occurs. Therefore, the
manner in which this should be addressed in the NTLP needs to be
considered.
Can path divergence be reduced at NSIS-aware nodes, since the node
knows about both the data flow and the NSIS signalling messages? i.e.
can it look at the flow identifier in the NTLP messages and calculate
the next hop directly from this, rather than constructing the NTLP
message and then routing normally?
At NSIS-unaware nodes performing policy forwarding the data and
signalling flows are more likely to diverge since the node is unaware
McDonald, et al. Expires July 24, 2003 [Page 8]
Internet-Draft NTLP Design Considerations January 2003
that they are related. The only real countermeasure is to make the
path selecting messages of the NSIS protocol look as much like the
data flow packets as possible (e.g. same source/destination
addresses, same DSCP, etc.).
The RSVP protocol does not attempt to directly tackle this form of
path divergence in the case of policy forwarding.
How should the NTLP tackle this form of path divergence? For example,
should the 'discovery' messages be made to look like the data flow?
3.4.2 Path Divergence Through Rerouting
When rerouting occurs the signalling data may continue to be sent
along the old route (particularly if signalling data is addressed
directly between NSIS peers). The NTLP should be capable of detecting
this and performing rerouting as required. How should NSIS entities
detect route changes, and how quickly should they react?
Some RSVP messages, such as Path messages, are addressed to the data
destination, and can usually be used to detect when rerouting of the
signalling path has occurred. RSVP assumes that this indicates also a
rerouting of the data flow.
In other cases (e.g. Resv and Bundle messages), the RSVP messages are
addressed directly to an RSVP neighbour. These cannot detect route
changes. In fact, it is forbidden to use Bundle messages when changes
in the next hop cannot be detected.
Since an NSIS capable router would also have the related data traffic
passing through it, can it use this information to detect when this
data flow 'disappears' due to rerouting and determine that the data
path has changed?
How should the NTLP work to ensure timely identification of route
changes to a data flow? Possibilities for route change identification
include:
o Local detection (e.g. routing local repair)
o Remote detection (e.g. by signalling application)
o Sending of (un-bundled) downstream signalling messages (basic RSVP
approach)
o Sending explicit signalling to verify the next peer identity (CASP
approach)
McDonald, et al. Expires July 24, 2003 [Page 9]
Internet-Draft NTLP Design Considerations January 2003
How should the NTLP react to data path changes? Should the protocol
explicitly define the state management (e.g. hold-down timers)
necessary to prevent spurious signalling, or should it assume this is
done 'externally' and react promptly itself? e.g. RSVP message
processing rules include such rules for processing Path messages to
mitigate route flapping problems. On the other hand, if the route
change is caused by a mobility event [13] a prompt reaction is
essential. Should the NTLP include different variants of peer
discovery messages to handle this type of issue? Is the selection of
a variant influenced by the NSLP being used?
4. NAT and Firewall Traversal
The NTLP/NSLP carry flow identifying information in their payloads.
This causes some 'NAT-unfriendliness', since the NAT must change
these payloads to reflect the way it has (or will) translate the data
flows.
For correct NAT traversal of RSVP packets the NAT must be able to
understand a number of RSVP object classes, including session
objects, hop objects, error specification objects, filter
specification objects, reservation confirmation objects.
NAT issues for RSVP are discussed in section 4.2 of [8], where the
need for an RSVP-ALG (Application Layer Gateway) is identified, as is
the fact that this will not work when RSVP Integrity objects are
being used.
Is it desirable to be able to support NSIS-aware NATs without them
requiring full NSIS support with a MIDCOM NSLP, and when NTLP is
being used for a flow without using a MIDCOM NSLP (i.e. when using
NSLPs other than MIDCOM)? Is it desirable to place any objects that
may need to be manipulated by the NAT in the NTLP, so that new NSLPs
can be defined without requiring modifications to the NAT?
If the NTLP is carried over TCP or SCTP, then flow state can be
expected to already be handled in most NATs and stateful firewalls.
Will an NTLP-ALG or NTLP entity in the NAT be used to perform the
translation on flow identifiers carried by the protocol?
5. State Location
The NSIS protocols will establish state along the signalling path.
One component of this is application state (which is relevant to the
NSLP). Also, there may be message transport state (which could be
hidden inside the NTLP). How are these state components related, and
what dependencies are there between the two parts?
McDonald, et al. Expires July 24, 2003 [Page 10]
Internet-Draft NTLP Design Considerations January 2003
Should the NTLP be directly or indirectly involved in managing NSLP
state?
What state should be held in the NTLP (if any)? And, what state
should be held by the various NSLPs? Should state held at the NTLP be
soft state? Can multiple NSLP states (from a single NSLP or different
NSLPs) be associated with a single NTLP "session"? What is the
relationship between the state lifetime at the NTLP and NSLP?
The concept of a split between 'NTLP' and 'NSLP' parts does not exist
in RSVP, so no prior implementation or design experience can be
gleaned from RSVP on this issue.
It is necessary to consider where to put state in the network. For
this it is necessary to consider whether the NTLP should be optimised
for (a) low latency at signalling start-up, or (b) low latency on
route changes. Based on the answer to that question, the protocol
might need to keep state either (a) at the edge of the network, or
(b) in the core (i.e. close to where the change occurs).
NTLP state identified within this draft, includes:
o Peer state, which includes:
* Presence
* Capabilities
* Status
* Negotiated parameters
o Routing state, including:
* Next hops
* Previous hops
o Security related state
o Session and flow identification
o NTLP configuration, such as:
* State for duplicate detection
* Data for potential retransmission
McDonald, et al. Expires July 24, 2003 [Page 11]
Internet-Draft NTLP Design Considerations January 2003
* RTT for congestion control
* Path MTU
How much state is needed for the protocol to work?
How much state is needed for the protocol to work efficiently?
How much state is needed for the error handling?
Should the NTLP do any merging of states/messages itself? Does the
NTLP perform "lazy forwarding" (e.g. in the style of RSVP with
refresh reduction, where messages representing a state change are
forwarded immediately, but refreshes can be sent as part of a summary
refresh)? Or, are these NSLP issues? In particular, if the NTLP does
not perform state management, then it cannot offer this type of
functionality.
6. Overload Protection
Protection against overload caused for malicious purposes is
discussed in Section 9.2.
What mechanisms should the NTLP provide to protect against overload
during normal use?
What overload protection capability the NTLP should provide as part
of the service for NSLPs? For example, should it provide flow
control?
7. Failure detection and Failover
The handling of re-routing to avoid path divergence is discussed in
Section 3.4.2, and has different requirements to the need to handle
NTLP failures.
Should the NTLP be able to detect and handle failures (e.g. lost NTLP
entities) itself?
Even if the NTLP does not perform failover itself, should it be
designed to allow easy failover by an NSLP? What are the constraints
on the NTLP that come from this?
Is a technique similar to the BGP Graceful Restart appropriate to
avoid rerouting and route flap when an NSIS entity restarts?
8. Feedback/Error Messages
McDonald, et al. Expires July 24, 2003 [Page 12]
Internet-Draft NTLP Design Considerations January 2003
What error conditions are relevant at the NTLP?
The NSIS protocols must support "transport" related errors and NSLP
(e.g. QoS) errors. RSVP does not make a (structural) distinction
between the two.
An example of an NTLP to NSLP (i.e. generated by an NTLP but consumed
by an NSLP) error message is an 'NSLP unreachable' message. It may be
that this is the only NTLP to NSLP error message, with other error
messages being either NTLP to NTLP or NSLP to NSLP.
Should the NTLP provide error handling functions on behalf of the
NSLPs? Or, must an NSLP handle errors itself?
What about ICMP errors (e.g. where an NTLP message is sent to a node
that doesn't support NTLP)? Are these correctly addressed? For
example, consider the case where an intermediate node between two
end-points sends out a message with the end-point addresses as the
source and destination (to avoid path divergence). What happens if
this results in an ICMP error message from further downstream? (This
error message will be sent to the source, but is actually of interest
to the intermediate node.)
How are ICMP errors processed in relation to the NTLP? (e.g. consider
UDP related ICMP port unreachable vs TCP RST processing)
Are errors sent hop-by-hop or not? For some types of error only the
originator of the message to which the error is a response should
process the error, in other cases it may be desirable for error
messages to affect state at intermediate entities. The latter
requires hop-by-hop error handling, the former case can be handled
either hop-by-hop or by direct addressing to the message originator.
An example of non-hop-by-hop message is the Notification message in
RSVP-TE which is transmitted directly to the source.
Is there a distinction between an NSLP path teardown and an NTLP
session termination? Does removing (for example) QoS reservation
state automatically remove path state, or is an explicit path
teardown required? Does a path teardown remove reservation state
automatically?
9. Security
It is assumed that at the NTLP layer the only security concerns are
for message protection and overload protection (protection against
malicious traffic), including the internal or external key management
mechanisms to support this.
McDonald, et al. Expires July 24, 2003 [Page 13]
Internet-Draft NTLP Design Considerations January 2003
It should be noted that the security mechanisms for the NTLP are
contingent on other aspects of the design.
9.1 Message Protection
Should the NTLP use an existing security mechanism (e.g. IPsec or
TLS)? Or, should a new security mechanism be developed for the NTLP
(e.g. in the style of the RSVP integrity mechanism)?
Should we reuse an existing key exchange protocol, or write our own?
(e.g. if rolling our own integrity protection mechanism)
How much flexibility does the security mechanism need to have? Should
the NTLP protocol specify a single solution for the complete security
problem? Or, are some parts of the NTLP operation different to others
(and so need different security mechanisms)?
How are nodes identified? How is identity information securely
exchanged?
9.2 Denial of Service Protection
Should the NTLP provide protection against flooding attacks itself?
Or, is it sufficient to rely on lower layers (e.g. SCTP cookies, IKE
cookies)?
Who is made to "work hard" during an attack? Is the flooder made to
suffer in any way? Where does the "attack" come from (e.g. can it be
forwarded down a series of NSIS entities)? Are the initial messages
sufficiently cheap that such attacks have little effect (e.g. what
state do they create)?
10. Message Objects and Extensibility
It is currently undecided whether any of the RSVP objects [15]
should be reused for the NTLP.
The message formatting may be required to support new NTLP message
types. Other protocols have used techniques such as marking objects
"optional" or "critical" to provide support for this.
RSVP allows unknown classes to be handled in different ways: the
entire message may rejected, the object may be ignored and not
forwarded, or the object may be ignored and forwarded. Unknown types
of object within a known class generally result in an error being
sent back. However, certain objects which are opaque to RSVP (e.g.
FLOWSPEC, ADSPEC, and POLICY_DATA) can be passed on to the relevant
module for a decision to be made.
McDonald, et al. Expires July 24, 2003 [Page 14]
Internet-Draft NTLP Design Considerations January 2003
The NTLP also needs to be able to handle new upper layer 'things'. It
is an open question as to whether these are specified as new
signalling applications, new types of signalling application, new
capabilities, additional optional aspects of a signalling
application, etc.
An NTLP is expected to be able to support multiple signalling
applications (e.g. QoS and MIDCOM). It is to be decided whether these
must be supported at the same time (both in the same NTLP message, or
both related to the same NTLP 'session' identifier).
11. Other Functionality
11.1 Scoping
Is it necessary to be able to specify a scope for a message (or
individual objects) in the NTLP? (Or, is the purely an NSLP concept?)
11.2 Inter/Intra Domain Use
Are there different modes of operation for intra/inter domain use?
How is this performed (e.g. having some functionality made optional
and only used in a particular mode of operation)?
11.3 Mobility Support
Mobility related issues are still to be considered. See [13] for some
discussion.
11.4 Session/State Identification
Issues relating session/state identification (including their
relationship to flow identification) are still to be considered.
12. Security Considerations
This design considerations document raises no security considerations
in and of itself. Design considerations relating to the security of
an NTLP protocol are given in Section 9.
Informative References
[1] Hancock, R. and I. Freytsis, "Next Steps in Signaling:
Framework", draft-ietf-nsis-fw-01 (work in progress), November
2002.
[2] Brunner, M., "Requirements for Signaling Protocols",
draft-ietf-nsis-req-06 (work in progress), December 2002.
McDonald, et al. Expires July 24, 2003 [Page 15]
Internet-Draft NTLP Design Considerations January 2003
[3] Nagle, J., "Congestion control in IP/TCP internetworks", RFC
896, January 1984.
[4] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[5] Baker, F., Lindell, B. and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[6] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914,
September 2000.
[7] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S.
Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC
2961, April 2001.
[8] Holdrege, M. and P. Srisuresh, "Protocol Complications with the
IP Network Address Translator", RFC 3027, January 2001.
[9] Braden, R. and B. Lindell, "A Two-Level Architecture for
Internet Signaling", draft-braden-2level-signal-arch-01 (work
in progress), November 2002.
[10] Hancock, R., "Sender and Receiver Orientation Issues in NSIS",
draft-hancock-nsis-sender-receiver-00 (work in progress),
October 2002.
[11] Schulzrinne, H., "CASP - Cross-Application Signaling Protocol",
draft-schulzrinne-nsis-casp-00 (work in progress), September
2002.
[12] Westberg, L., "Using RSVPv1 as NTLP (NSIS Transport Layer
Protocol): suggestions for modifications on RFC2205",
draft-westberg-nsis-rsvp-as-ntlp-00 (work in progress), January
2003.
[13] Thomas, M., "Analysis of Mobile IP and RSVP Interactions",
draft-thomas-nsis-rsvp-analysis-00 (work in progress), November
2002.
[14] Aboba, B. and J. Wood, "Authentication, Authorization and
Accounting (AAA) Transport Profile",
draft-ietf-aaa-transport-12 (work in progress), January 2003.
[15] <http://www.iana.org/assignments/rsvp-parameters>
McDonald, et al. Expires July 24, 2003 [Page 16]
Internet-Draft NTLP Design Considerations January 2003
Authors' Addresses
Andrew McDonald
Siemens/Roke Manor Research
Old Salisbury Lane
Romsey, Hampshire SO51 0ZN
United Kingdom
EMail: andrew.mcdonald@roke.co.uk
Robert Hancock
Siemens/Roke Manor Research
Old Salisbury Lane
Romsey, Hampshire SO51 0ZN
United Kingdom
EMail: robert.hancock@roke.co.uk
Eleanor Hepworth
Siemens/Roke Manor Research
Old Salisbury Lane
Romsey, Hampshire SO51 0ZN
United Kingdom
EMail: eleanor.hepworth@roke.co.uk
McDonald, et al. Expires July 24, 2003 [Page 17]
Internet-Draft NTLP Design Considerations January 2003
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
McDonald, et al. Expires July 24, 2003 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-23 20:20:54 |