The requests MUST include the following:
- Information about the organization that will administer the
ITAD.
- Contact information (postal and email address).
14. Security Considerations
This section covers security between peer TRIP LSs when TRIP runs
over TCP in an IP environment.
A security mechanism is clearly needed to prevent unauthorized
entities from using the protocol defined in this document for setting
up unauthorized peer sessions with other TRIP LSs or interfering with
authorized peer sessions. The security mechanism for the protocol,
when transported over TCP in an IP network, is IPsec [12]. IPsec
uses two protocols to provide traffic security: Authentication Header
(AH) [13] and Encapsulating Security Payload (ESP) [14].
The AH header affords data origin authentication, connectionless
integrity and optional anti-replay protection of messages passed
between the peer LSs. The ESP header provides origin authentication,
connectionless integrity, anti-replay protection, and confidentiality
of messages.
Implementations of the protocol defined in this document employing
the ESP header SHALL comply with section 5 of [14], which defines a
minimum set of algorithms for integrity checking and encryption.
Similarly, implementations employing the AH header SHALL comply with
section 5 of [13], which defines a minimum set of algorithms for
integrity checking using manual keys.
Implementations SHOULD use IKE [15] to permit more robust keying
options. Implementations employing IKE SHOULD support authentication
with RSA signatures and RSA public key encryption.
A Security Association (SA) [12] is a simplex "connection" that
affords security services to the traffic carried by it. Security
services are afforded to a SA by the use of AH, or ESP, but not both.
Two types of SAs are defined: transport mode and tunnel mode [12]. A
transport mode SA is a security association between two hosts, and is
appropriate for protecting the TRIP session between two peer LSs.
A1. Appendix 1: TRIP FSM State Transitions and Actions
This Appendix discusses the transitions between states in the TRIP
FSM in response to TRIP events. The following is the list of these
states and events when the negotiated Hold Time value is non-zero.
TRIP States:
1 - Idle
2 - Connect
3 - Active
4 - OpenSent
5 - OpenConfirm
6 - Established
TRIP Events:
1 - TRIP Start
2 - TRIP Stop
3 - TRIP Transport connection open
4 - TRIP Transport connection closed
5 - TRIP Transport connection open failed
6 - TRIP Transport fatal error
7 - ConnectRetry timer expired
8 - Hold Timer expired
9 - KeepAlive timer expired
10 - Receive OPEN message
11 - Receive KEEPALIVE message
12 - Receive UPDATE messages
13 - Receive NOTIFICATION message
The following table describes the state transitions of the TRIP FSM
and the actions triggered by these transitions.
Event Actions Message Sent Next State
--------------------------------------------------------------------
Idle (1)
1 Initialize resources none 2
Start ConnectRetry timer
Initiate a transport connection
others none none 1
Connect(2)
1 none none 2
3 Complete initialization OPEN 4
Clear ConnectRetry timer
5 Restart ConnectRetry timer none 3
7 Restart ConnectRetry timer none 2
Initiate a transport connection
others Release resources none 1
Active (3)
1 none none 3
3 Complete initialization OPEN 4
Clear ConnectRetry timer
5 Close connection 3
Restart ConnectRetry timer
7 Restart ConnectRetry timer none 2
Initiate a transport connection
others Release resources none 1
OpenSent(4)
1 none none 4
4 Close transport connection none 3
Restart ConnectRetry timer
6 Release resources none 1
10 Process OPEN is OK KEEPALIVE 5
Process OPEN failed NOTIFICATION 1
others Close transport connection NOTIFICATION 1
Release resources
OpenConfirm (5)
1 none none 5
4 Release resources none 1
6 Release resources none 1
9 Restart KeepAlive timer KEEPALIVE 5
11 Complete initialization none 6
Restart Hold Timer
13 Close transport connection 1
Release resources
others Close transport connection NOTIFICATION 1
Release resources
Established (6)
1 none none 6
4 Release resources none 1
6 Release resources none 1
9 Restart KeepAlive timer KEEPALIVE 6
11 Restart Hold Timer none 6
12 Process UPDATE is OK UPDATE 6
Process UPDATE failed NOTIFICATION 1
13 Close transport connection 1
Release resources
others Close transport connection NOTIFICATION 1
Release resources
-----------------------------------------------------------------
The following is a condensed version of the above state transition
table.
Events| Idle | Connect | Active | OpenSent | OpenConfirm | Estab
| (1) | (2) | (3) | (4) | (5) | (6)
|----------------------------------------------------------
1 | 2 | 2 | 3 | 4 | 5 | 6
| | | | | |
2 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
3 | 1 | 4 | 4 | 1 | 1 | 1
| | | | | |
4 | 1 | 1 | 1 | 3 | 1 | 1
| | | | | |
5 | 1 | 3 | 3 | 1 | 1 | 1
| | | | | |
6 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
7 | 1 | 2 | 2 | 1 | 1 | 1
| | | | | |
8 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
9 | 1 | 1 | 1 | 1 | 5 | 6
| | | | | |
10 | 1 | 1 | 1 | 1 or 5 | 1 | 1
| | | | | |
11 | 1 | 1 | 1 | 1 | 6 | 6
| | | | | |
12 | 1 | 1 | 1 | 1 | 1 | 1 or 6
| | | | | |
13 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
--------------------------------------------------------------
A2. Appendix 2: Implementation Recommendations
This section presents some implementation recommendations.
A.2.1: Multiple Networks Per Message
The TRIP protocol allows for multiple address prefixes with the same
advertisement path and next-hop server to be specified in one
message. Making use of this capability is highly recommended. With
one address prefix per message there is a substantial increase in
overhead in the receiver. Not only does the system overhead increase
due to the reception of multiple messages, but the overhead of
scanning the routing table for updates to TRIP peers is incurred
multiple times as well. One method of building messages containing
many address prefixes per advertisement path and next hop from a
routing table that is not organized per advertisement path is to
build many messages as the routing table is scanned. As each address
prefix is processed, a message for the associated advertisement path
and next hop is allocated, if it does not exist, and the new address
prefix is added to it. If such a message exists, the new address
prefix is just appended to it. If the message lacks the space to
hold the new address prefix, it is transmitted, a new message is
allocated, and the new address prefix is inserted into the new
message. When the entire routing table has been scanned, all
allocated messages are sent and their resources released. Maximum
compression is achieved when all the destinations covered by the
address prefixes share the same next hop server and common
attributes, making it possible to send many address prefixes in one
4096-byte message.
When peering with a TRIP implementation that does not compress
multiple address prefixes into one message, it may be necessary to
take steps to reduce the overhead from the flood of data received
when a peer is acquired or a significant network topology change
occurs. One method of doing this is to limit the rate of updates.
This will eliminate the redundant scanning of the routing table to
provide flash updates for TRIP peers. A disadvantage of this
approach is that it increases the propagation latency of routing
information. By choosing a minimum flash update interval that is not
much greater than the time it takes to process the multiple messages,
this latency should be minimized. A better method would be to read
all received messages before sending updates.
A.2.2: Processing Messages on a Stream Protocol
TRIP uses TCP as a transport mechanism. Due to the stream nature of
TCP, all the data of a received message does not necessarily arrive
at the same time. This can make it difficult to process the data as
messages, especially on systems where it is not possible to determine
how much data has been received but not yet processed.
One method that can be used in this situation is to first try to read
just the message header. For the KEEPALIVE message type, this is a
complete message; for other message types, the header should first be
verified, in particular the total length. If all checks are
successful, the specified length, minus the size of the message
header is the amount of data left to read. An implementation that
would "hang" the routing information process while trying to read
from a peer could set up a message buffer (4096 bytes) per peer and
fill it with data as available until a complete message has been
received.
A.2.3: Reducing Route Flapping
To avoid excessive route flapping an LS which needs to withdraw a
destination and send an update about a more specific or less specific
route SHOULD combine them into the same UPDATE message.
A.2.4: TRIP Timers
TRIP employs seven timers: ConnectRetry, Hold Time, KeepAlive,
MaxPurgeTime, TripDisableTime, MinITADOriginationInterval, and
MinRouteAdvertisementInterval. The suggested value for the
ConnectRetry timer is 120 seconds. The suggested value for the Hold
Time is 90 seconds. The suggested value for the KeepAlive timer is
30 seconds. The suggested value for the MaxPurgeTime timer is 10
seconds. The suggested value for the TripDisableTime timer is 180
seconds. The suggested value for the MinITADOriginationInterval is
30 seconds. The suggested value for the
MinRouteAdvertisementInterval is 30 seconds.
An implementation of TRIP MUST allow these timers to be configurable.
A.2.5: AP_SET Sorting
Another useful optimization that can be done to simplify this
situation is to sort the ITAD numbers found in an AP_SET. This
optimization is entirely optional.
Acknowledgments
We wish to thank Dave Oran for his insightful comments and
suggestions.
References
[1] Bradner, S., "Keywords for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[2] Rosenberg, J. and H. Schulzrinne, "A Framework for a Gateway
Location Protocol", RFC2871, June 2000.
[3] Rekhter, Y. and T. Li, "Border Gateway Protocol 4 (BGP-4)," RFC
1771, March 1995.
[4] Moy, J., "Open Shortest Path First Version 2", STD 54, RFC
2328, April 1998.
[5] "Intermediate System to Intermediate System Intra-Domain
Routing Exchange Protocol for use in Conjunction with the
Protocol for Providing the Connectionless-mode Network Service
(ISO 8473)," ISO DP 10589, February 1990.
[6] Luciani, J., Armitage, G., Halpern, J. and N. Doraswamy,
"Server Cache Synchronization Protocol (SCSP)", RFC2334, April
1998.
[7] International Telecommunication Union, "Packet-Based Multimedia
Communication Systems," Recommendation H.323, Version 3
Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, November 2000.
[8] Handley, H., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC2543, March 1999.
[9] Braden, R., "Requirements for Internet Hosts -- Application and
Support", STD 3, RFC1123, October 1989.
[10] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC2373, July 1998.
[11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC2434, October
1998.
[12] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC2401, November 1998.
[13] Kent, S. and R. Atkinson, "IP Authentication Header", RFC2402,
November 1998.
[14] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC2406, November 1998.
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC2409, November 1998.
Intellectual Property Notice
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP 11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Authors' Addresses
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
Phone: 973-952-5000
EMail: jdrosen@dynamicsoft.com
Hussein F. Salama
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
Phone: 408-527-7147
EMail: hsalama@cisco.com
Matt Squire
Hatteras Networks
639 Davis Drive
Suite 200
Durham, NC 27713
EMail: mattsquire@acm.org
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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 assigns.
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 RFCEditor function is currently provided by the
Internet Society.