draft-ietf-rserpool-asap-07.txt   draft-ietf-rserpool-asap-08.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: November 13, 2003 Q. Xie Expires: April 20, 2004 Q. Xie
Motorola, Inc. Motorola, Inc.
M. Stillman M. Stillman
Nokia Nokia
M. Tuexen M. Tuexen
May 15, 2003 October 21, 2003
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
draft-ietf-rserpool-asap-07.txt draft-ietf-rserpool-asap-08.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 13, 2003. This Internet-Draft will expire on April 20, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
Aggregate Server Access Protocol (ASAP) in conjunction with the Aggregate Server Access Protocol (ASAP) in conjunction with the
Endpoint Name Resolution Protocol (ENRP) [6] provides a high Endpoint Name Resolution Protocol (ENRP) [6] provides a high
availability data transfer mechanism over IP networks. ASAP uses a availability data transfer mechanism over IP networks. ASAP uses a
skipping to change at page 3, line 42 skipping to change at page 3, line 42
3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 17 3.2 Deregistration . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Name resolution . . . . . . . . . . . . . . . . . . . . . 18 3.3 Name resolution . . . . . . . . . . . . . . . . . . . . . 18
3.4 Endpoint keep alive . . . . . . . . . . . . . . . . . . . 19 3.4 Endpoint keep alive . . . . . . . . . . . . . . . . . . . 19
3.5 Reporting unreachable endpoints . . . . . . . . . . . . . 20 3.5 Reporting unreachable endpoints . . . . . . . . . . . . . 20
3.6 ENRP server hunt procedures . . . . . . . . . . . . . . . 20 3.6 ENRP server hunt procedures . . . . . . . . . . . . . . . 20
3.7 Handle ASAP to ENRP Communication Failures . . . . . . . . 22 3.7 Handle ASAP to ENRP Communication Failures . . . . . . . . 22
3.7.1 SCTP Send Failure . . . . . . . . . . . . . . . . . . . . 22 3.7.1 SCTP Send Failure . . . . . . . . . . . . . . . . . . . . 22
3.7.2 T1-ENRPrequest Timer Expiration . . . . . . . . . . . . . 22 3.7.2 T1-ENRPrequest Timer Expiration . . . . . . . . . . . . . 22
3.8 Cookie handling procedures . . . . . . . . . . . . . . . . 23 3.8 Cookie handling procedures . . . . . . . . . . . . . . . . 23
3.9 Business Card handling procedures . . . . . . . . . . . . 23 3.9 Business Card handling procedures . . . . . . . . . . . . 23
4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . 24 4. The ASAP Interfaces . . . . . . . . . . . . . . . . . . . 25
4.1 Registration.Request Primitive . . . . . . . . . . . . . . 24 4.1 Registration.Request Primitive . . . . . . . . . . . . . . 25
4.2 Deregistration.Request Primitive . . . . . . . . . . . . . 24 4.2 Deregistration.Request Primitive . . . . . . . . . . . . . 25
4.3 Cache.Populate.Request Primitive . . . . . . . . . . . . . 25 4.3 Cache.Populate.Request Primitive . . . . . . . . . . . . . 26
4.4 Cache.Purge.Request Primitive . . . . . . . . . . . . . . 25 4.4 Cache.Purge.Request Primitive . . . . . . . . . . . . . . 26
4.5 Data.Send.Request Primitive . . . . . . . . . . . . . . . 25 4.5 Data.Send.Request Primitive . . . . . . . . . . . . . . . 26
4.5.1 Sending to a Pool Handle . . . . . . . . . . . . . . . . . 26 4.5.1 Sending to a Pool Handle . . . . . . . . . . . . . . . . . 27
4.5.2 Pool Element Selection . . . . . . . . . . . . . . . . . . 27 4.5.2 Pool Element Selection . . . . . . . . . . . . . . . . . . 28
4.5.3 Sending to a Pool Element Handle . . . . . . . . . . . . . 28 4.5.3 Sending to a Pool Element Handle . . . . . . . . . . . . . 29
4.5.4 Send by Transport Address . . . . . . . . . . . . . . . . 29 4.5.4 Send by Transport Address . . . . . . . . . . . . . . . . 30
4.5.5 Message Delivery Options . . . . . . . . . . . . . . . . . 29 4.5.5 Message Delivery Options . . . . . . . . . . . . . . . . . 30
4.6 Data.Received Notification . . . . . . . . . . . . . . . . 31 4.6 Data.Received Notification . . . . . . . . . . . . . . . . 32
4.7 Error.Report Notification . . . . . . . . . . . . . . . . 31 4.7 Error.Report Notification . . . . . . . . . . . . . . . . 32
4.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 31 4.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.8.1 Send to a New Pool . . . . . . . . . . . . . . . . . . . . 32 4.8.1 Send to a New Pool . . . . . . . . . . . . . . . . . . . . 33
4.8.2 Send to a Cached Pool Handle . . . . . . . . . . . . . . . 33 4.8.2 Send to a Cached Pool Handle . . . . . . . . . . . . . . . 34
4.9 PE send failure . . . . . . . . . . . . . . . . . . . . . 33 4.9 PE send failure . . . . . . . . . . . . . . . . . . . . . 34
4.9.1 Translation.Request Primitive . . . . . . . . . . . . . . 34 4.9.1 Translation.Request Primitive . . . . . . . . . . . . . . 35
4.9.2 Transport.Failure Primitive . . . . . . . . . . . . . . . 34 4.9.2 Transport.Failure Primitive . . . . . . . . . . . . . . . 35
5. Variables, Timers, and Thresholds . . . . . . . . . . . . 35 5. Timers, Variables, and Thresholds . . . . . . . . . . . . 36
5.1 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.1 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Thresholds and Variables . . . . . . . . . . . . . . . . . 35 5.2 Variables . . . . . . . . . . . . . . . . . . . . . . . . 36
6. Security Considerations . . . . . . . . . . . . . . . . . 36 5.3 Thresholds . . . . . . . . . . . . . . . . . . . . . . . . 36
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 37 6. Security Considerations . . . . . . . . . . . . . . . . . 37
Normative References . . . . . . . . . . . . . . . . . . . 38 6.1 Implementing Security Mechanisms . . . . . . . . . . . . . 38
Informational References (non-normative) . . . . . . . . . 39 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 39 Normative References . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . 40 Informational References (non-normative) . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . 43
1. Introduction 1. Introduction
Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [6] Aggregate Server Access Protocol (ASAP) in conjunction with ENRP [6]
provides a high availability data transfer mechanism over IP provides a high availability data transfer mechanism over IP
networks. ASAP uses a name-based addressing model which isolates a networks. ASAP uses a name-based addressing model which isolates a
logical communication endpoint from its IP address(es), thus logical communication endpoint from its IP address(es), thus
effectively eliminating the binding between the communication effectively eliminating the binding between the communication
endpoint and its physical IP address(es) which normally constitutes a endpoint and its physical IP address(es) which normally constitutes a
single point of failure. single point of failure.
skipping to change at page 12, line 31 skipping to change at page 12, line 31
2.2.7 ENDPOINT_KEEP_ALIVE message 2.2.7 ENDPOINT_KEEP_ALIVE message
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x7 |0|0|0|0|0|0|0|0| Message Length | | Type = 0x7 |0|0|0|0|0|0|0|0| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Pool Handle Parameter : : Pool Handle Parameter :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message is sent to a PE by the ENRP server has a "health" check. This message is sent to a PE by the ENRP server as a "health" check.
If the transport level Heart Beat mechanism is insufficient (usually If the transport level Heart Beat mechanism is insufficient, this
this means that time outs are set for too long or heartbeats are not adds heartbeat messages with the goal of determining health status at
frequent enough), this adds heartbeat messages with the goal of ASAP level in a possibly more timely fashion. (The transport level
determining health status in a more timely fashion. Heart Beat may sometimes be considered insufficient due to that time
outs are set for too long or heartbeats are not frequent enough, or,
that the transport level Heart Beat mechanism's coverage is limited
only to the transport level at the two ends.)
Using ASAP keepalive also has additional value to the reliability of Using ASAP keepalive also has additional value to the reliability of
fault detection when SCTP stack is in the kernel. In such a case, fault detection when SCTP stack is in the kernel. In such a case,
while SCTP level heartbeat monitors the end-to-end connectivity while SCTP level heartbeat monitors the end-to-end connectivity
between the two SCTP stacks, ASAP keepalive monitors the end-to-end between the two SCTP stacks, ASAP keepalive monitors the end-to-end
liveliness of the ASAP layer above it. liveliness of the ASAP layer above it.
2.2.8 ENDPOINT_KEEP_ALIVE_ACK message 2.2.8 ENDPOINT_KEEP_ALIVE_ACK message
0 1 2 3 0 1 2 3
skipping to change at page 17, line 48 skipping to change at page 17, line 48
When re-registering the PE MUST use the same PE identifier. When re-registering the PE MUST use the same PE identifier.
After successful registration the PE MUST start a T4-reregistration After successful registration the PE MUST start a T4-reregistration
timer. At its expiration a re-registration SHOULD be made starting at timer. At its expiration a re-registration SHOULD be made starting at
step R1 including (at completion) restarting the T4-reregistration step R1 including (at completion) restarting the T4-reregistration
timer. timer.
Note that an implementation SHOULD keep a record of the number of Note that an implementation SHOULD keep a record of the number of
registration attempts it makes in a local variable. If repeated registration attempts it makes in a local variable. If repeated
registration time-outs or failures occurs and the local count exceeds registration time-outs or failures occurs and the local count exceeds
the Threshold 'max-reg-attempt' the implementation SHOULD report the the Threshold 'MAX-REG-ATTEMPT' the implementation SHOULD report the
error to its upper layer and stop attempting registration. error to its upper layer and stop attempting registration.
3.2 Deregistration 3.2 Deregistration
In the event the PE wishes to deregister from its server pool In the event the PE wishes to deregister from its server pool
(normally via an upper layer requests see Section 4.2) it SHOULD use (normally via an upper layer requests see Section 4.2) it SHOULD use
the following procedures. Note that an alternate method of the following procedures. Note that an alternate method of
deregistration is to NOT re-register and to allow the registration deregistration is to NOT re-register and to allow the registration
lift time to expire. lift time to expire.
When deregistering the PE SHOULD use the same SCTP association with When deregistering the PE SHOULD use the same SCTP association with
skipping to change at page 20, line 29 skipping to change at page 20, line 29
KA2.3) Send off the ENDPOINT_KEEP_ALIVE_ACK message via the KA2.3) Send off the ENDPOINT_KEEP_ALIVE_ACK message via the
appropriate SCTP association for that ENRP server. appropriate SCTP association for that ENRP server.
KA2.4) Adopt the sender of the ENDPOINT_KEEP_ALIVE message as the KA2.4) Adopt the sender of the ENDPOINT_KEEP_ALIVE message as the
new home ENRP server. new home ENRP server.
3.5 Reporting unreachable endpoints 3.5 Reporting unreachable endpoints
Occasionally an ASAP endpoint may realize that a PE is unreachable. Occasionally an ASAP endpoint may realize that a PE is unreachable.
This may occur by a specific SCTP error realized by the ASAP endpoint This may occur by a specific SCTP error realized by the ASAP endpoint
or via a ASAP user report via the Transport.Failure Primitive or via an ASAP user report via the Transport.Failure Primitive
(Section 4.9.2). In either case the ASAP endpoint SHOULD report the (Section 4.9.2). In either case the ASAP endpoint SHOULD report the
unavailability of the PE by sending a ENDPOINT_UNREACHABLE message to unavailability of the PE by sending an ENDPOINT_UNREACHABLE message
its home ENRP server. The Endpoint should fill in the Pool Handle and to its home ENRP server. The Endpoint should fill in the Pool Handle
PE identifier of the unreachable endpoint. If the sender is a PE the and PE identifier of the unreachable endpoint. If the sender is a PE
message MUST be sent via SCTP to the Endpoints Home ENRP server. the message MUST be sent via SCTP to the Endpoints Home ENRP server.
Note: an ASAP endpoint MUST report No more than once each time it
encounters such an event.
Note: when processing a Transport.Failure Primitive (Section 4.9.2) Note: when processing a Transport.Failure Primitive (Section 4.9.2)
the ASAP endpoint MUST NOT send a unreachable report unless the ASAP the ASAP endpoint MUST NOT send a unreachable report unless the ASAP
endpoint as sent at least one message to the PE specified by the endpoint has sent at least one message to the PE specified by the
primitive. primitive.
3.6 ENRP server hunt procedures 3.6 ENRP server hunt procedures
Each PU and PE manages a list of transport addresses of ENRP servers. Each PU and PE manages a list of transport addresses of ENRP servers.
If the multicast capabilities are used an ENRP server MUST send If the multicast capabilities are used an ENRP server MUST send
periodically every T6-Serverannounce a SERVER_ANNOUNE message periodically every T6-Serverannounce a SERVER_ANNOUNE message
(Section 2.2.10) including all the transport addresses available for (Section 2.2.10) including all the transport addresses available for
ASAP communication to the multicast channel. ASAP communication to the multicast channel.
skipping to change at page 22, line 45 skipping to change at page 22, line 48
message. Instead, it should discard the failed message and start the message. Instead, it should discard the failed message and start the
ENRP server hunt procedure as described in Section 3.6 ENRP server hunt procedure as described in Section 3.6
3.7.2 T1-ENRPrequest Timer Expiration 3.7.2 T1-ENRPrequest Timer Expiration
When a T1-ENRPrequest timer expires, the ASAP should re-send the When a T1-ENRPrequest timer expires, the ASAP should re-send the
original request to the ENRP server and re-start the T1-ENRPrequest original request to the ENRP server and re-start the T1-ENRPrequest
timer. In parallel, a SERVER_HUNT message should be issued per timer. In parallel, a SERVER_HUNT message should be issued per
Section 3.6 Section 3.6
This should be repeated up to 'max-request-retransmit' times. After This should be repeated up to 'MAX-REQUEST-RETRANSMIT' times. After
that, an Error.Report notification should be generated to inform the that, an Error.Report notification should be generated to inform the
ASAP user and the ENRP request message associated with the timer ASAP user and the ENRP request message associated with the timer
should be discarded. Note that if an alternate ENRP server responds should be discarded. Note that if an alternate ENRP server responds
the ASAP endpoint SHOULD adopt the responding ENRP server as its new the ASAP endpoint SHOULD adopt the responding ENRP server as its new
"home" server and resend the request to the new "home" server. "home" server and resend the request to the new "home" server.
3.8 Cookie handling procedures 3.8 Cookie handling procedures
Whenever a PE wants and a control channel exists it can send a Cookie Whenever a PE wants and a control channel exists it can send a Cookie
Message to the PU via the control channel. The ASAP layer at the PU Message to the PU via the control channel. The ASAP layer at the PU
skipping to change at page 34, line 29 skipping to change at page 35, line 29
addresses to the caller. addresses to the caller.
4.9.2 Transport.Failure Primitive 4.9.2 Transport.Failure Primitive
Format: transport.failure(Pool-Handle, Transport-address) Format: transport.failure(Pool-Handle, Transport-address)
If an external user encounters a failure in sending to a PE and is If an external user encounters a failure in sending to a PE and is
NOT using ASAP it can use this primitive to report the failure to the NOT using ASAP it can use this primitive to report the failure to the
ASAP endpoint. ASAP will send ENDPOINT_UNREACHABLE to the "home" ENRP ASAP endpoint. ASAP will send ENDPOINT_UNREACHABLE to the "home" ENRP
server in response to this primitive. Note ASAP SHOULD NOT send a server in response to this primitive. Note ASAP SHOULD NOT send a
ENDPOINT_UNREACHABLE UNLESS the user as actually made a previous ENDPOINT_UNREACHABLE UNLESS the user has actually made a previous
request to send data to the PE. request to send data to the PE.
5. Variables, Timers, and Thresholds 5. Timers, Variables, and Thresholds
The following is a summary of the variables, timers, and pre-set The following is a summary of the timers, variables, and pre-set
protocol constants used in ASAP. protocol constants used in ASAP.
5.1 Timers 5.1 Timers
T1-ENRPrequest - A timer started when a request is sent by ASAP to T1-ENRPrequest - A timer started when a request is sent by ASAP to
the ENRP server (providing application information is queued). the ENRP server (providing application information is queued).
Normally set to 15 seconds. Normally set to 15 seconds.
T2-registration - A timer started when sending a registration request T2-registration - A timer started when sending a registration request
to the home ENRP server, normally set to 30 seconds. to the home ENRP server, normally set to 30 seconds.
skipping to change at page 35, line 38 skipping to change at page 36, line 38
T5-Serverhunt - This timer is used during the ENRP server hunt T5-Serverhunt - This timer is used during the ENRP server hunt
procedure and is normally set to 120 seconds. procedure and is normally set to 120 seconds.
T6-Serverannounce - This timer gives the time between the sending of T6-Serverannounce - This timer gives the time between the sending of
consecutive SERVER_ANNOUNCE messages. It is normally set to 1 consecutive SERVER_ANNOUNCE messages. It is normally set to 1
second. second.
T7-ENRPoutdate - This timer gives the time a server announcement is T7-ENRPoutdate - This timer gives the time a server announcement is
valid. It is normally set to 5 seconds. valid. It is normally set to 5 seconds.
5.2 Thresholds and Variables 5.2 Variables
max-reg-attempt - The maximum number of registration attempts to be stale.cache.value - A threshold variable that indicates how long a
cache entry is valid for.
5.3 Thresholds
MAX-REG-ATTEMPT - The maximum number of registration attempts to be
made before a server hunt is issued. made before a server hunt is issued.
max-request-retransmit - The maximum number of attempts to be made MAX-REQUEST-RETRANSMIT - The maximum number of attempts to be made
when requesting information from the local ENRP server before a when requesting information from the local ENRP server before a
server hunt is issued. server hunt is issued.
stale.cache.value - A threshold variable that indicates how long a
cache entry is valid for.
6. Security Considerations 6. Security Considerations
Due to varying requirements and multiple use cases of Rserpool, we Threats Introduced by Rserpool and Requirements for Security in
point out two basic security protocols, IPsec and TLS. We Response to Threats [7] describes the threats to the Rserpool
specifically do not discuss whether one security protocol would be architecture in detail and lists the security requirements in
preferred over the other. This choice will be made by designers and response to each threat. From the threats described in this document,
network architects based on system requirements. the security services required for the Rserpool protocol are
enumerated below.
For networks that demand IPsec security, implementations MUST support Threat 1) PE registration/deregistration flooding or spoofing
SCTPIPSEC [7] which describes IPsec-SCTP. IPsec is two layers below -----------
RSerPool. Therefore, if IPsec is used for securing Rserpool, no Security mechanism in response: ENRP server authenticates the PE
changes or special considerations need to be made to Rserpool to
secure the protocol.
For networks that cannot or do not wish to use IPsec and prefer Threat 2) PE registers with a malicious ENRP server
instead TLS, implementations MUST support TLS with SCTP as described -----------
in RFC3436 [8] or TLS over TCP as described in RFC2246 [3] When using Security mechanism in response: PE authenticates the ENRP server
TLS/SCTP we must ensure that RSerPool does not use any features of
SCTP that are not available to an TLS/SCTP user. This is not a
difficult technical problem, but simply a requirement. When
describing an API of the RSerPool lower layer we have also to take
into account the differences between TLS and SCTP. This is also not
difficult, but it is in contrast to the IPsec solution which is
transparently layered below Rserpool.
Support for security is required for the ENRP server and the PEs. Threat 1 and 2 taken together results in mutual authentication of the
Security support for the Rserpool end user is optional. Note that ENRP server and the PE.
the end user implementation contains a piece of the Rserpool protocol
-- namely ASAP -- whereby the pool handle is passed for name
resolution to the ENRP server and IP address(es) are returned.
The argument for optional end user security is as follows: If the Threat 3) Malicious ENRP server joins the ENRP server pool
user doesn't require security protection for example, against -----------
eavesdropping for the request for pool handle resolution and Security mechanism in response: ENRP servers mutually authenticate
response, then they are free to make that choice. However, if the
end user does require security, they are guaranteed to get it due to Threat 4) A PU communicates with a malicious ENRP server for name
the requirement for security support for the ENRP server. It is also resolution
possible for the ENRP server to reject an unsecured request from the -----------
user due to its security policy in the case that it requires Security mechanism in response: The PU authenticates the ENRP server
enforcement of strong security. But this will be determined by the
security requirements of the individual network design. Threat 5) Replay attack
-----------
Security mechanism in response: Security protocol which has
protection from replay attacks
Threat 6) Corrupted data which causes a PU to have misinformation
concerning a pool handle resolution
-----------
Security mechanism in response: Security protocol which supports
integrity protection
Threat 7) Eavesdropper snooping on namespace information
-----------
Security mechanism in response: Security protocol which supports data
confidentiality
Threat 8) Flood of Endpoint_Unreachable messages from the PU to ENRP
server
-----------
Security mechanism in response: ASAP must control the number of
endpoint unreachable messages transmitted from the PU to the ENRP
server.
Threat 9) Flood of Endpoint_KeepAlive messages to the PE from the
ENRP server
-----------
Security mechanism in response: ENRP server must control the number
of Endpoint_KeepAlive messages to the PE
To summarize the threats 1-7 require security mechanisms which
support authentication, integrity, data confidentiality, protection
from replay attacks.
For Rserpool we need to authenticate the following:
PU <---- ENRP Server (PU authenticates the ENRP server)
PE <----> ENRP Server (mutual authentication)
ENRP server <-----> ENRP Server (mutual authentication)
We do not define any new security mechanisms specifically for
responding to threats 1-7. Rather we use existing IETF security
protocols to provide the security services required. TLS supports all
these requirements and MUST be implemented. The
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite MUST be supported at a
minimum by implementers of TLS for Rserpool. For purposes of
backwards compatibility, ENRP SHOULD support
TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any
other ciphersuite.
Threat 8 requires the ASAP protocol to limit the number of
Endpoint_Unreachable messages (see Section 3.5) to the ENRP server.
Threat 9 requires the ENRP protocol to limit the number of
Endpoint_KeepAlive messages to the PE (see section x.y??? in [6]).
6.1 Implementing Security Mechanisms
ENRP servers, PEs, PUs MUST implement TLS. ENRP servers and PEs must
support mutual authentication. ENRP servers must support mutual
authentication among themselves. PUs MUST authenticate ENRP servers.
ENRP servers and PEs SHOULD possess a site certificate whose subject
corresponds to their canonical hostname. PUs MAY have certificates
of their own for mutual authentication with TLS, but no provisions
are set forth in this document for their use. All Rserpool elements
that support TLS MUST have a mechanism for validating certificates
received during TLS negotiation; this entails possession of one or
more root certificates issued by certificate authorities (preferably
well-known distributors of site certificates comparable to those that
issue root certificates for web browsers).
Implementations MUST support TLS with SCTP as described in RFC3436
[8] or TLS over TCP as described in RFC2246 [3]. When using TLS/SCTP
we must ensure that RSerPool does not use any features of SCTP that
are not available to an TLS/SCTP user. This is not a difficult
technical problem, but simply a requirement. When describing an API
of the RSerPool lower layer we have also to take into account the
differences between TLS and SCTP.
7. Acknowledgments 7. Acknowledgments
The authors wish to thank Thomas Dreibholz, John Loughney, Lyndon The authors wish to thank Thomas Dreibholz, John Loughney, Lyndon
Ong, and many others for their invaluable comments. Ong, and many others for their invaluable comments.
Normative References Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
skipping to change at page 38, line 22 skipping to change at page 41, line 22
[3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and [3] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1999. 1999.
[4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[5] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate [5] Stewart, R., Xie, Q., Stillman, M. and M. Tuexen, "Aggregate
Server Access Protocol and Endpoint Name Resolution Protocol Server Access Protocol (ASAP) and Endpoint Name Resolution
Common Parameters", draft-ietf-rserpool-common-param-01 (work in Protocol (ENRP) Parameters", draft-ietf-rserpool-common-param-04
progress), June 2002. (work in progress), May 2003.
[6] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution [6] Xie, Q., Stewart, R. and M. Stillman, "Enpoint Name Resolution
Protocol (ENRP)", draft-ietf-rserpool-enrp-04 (work in Protocol (ENRP)", draft-ietf-rserpool-enrp-07 (work in
progress), May 2002. progress), October 2003.
[7] Bellovin, S., "On the Use of SCTP with IPsec", [7] Stillman, M., "Threats Introduced by Rserpool and Requirements
draft-ietf-ipsec-sctp-06 (work in progress), April 2003. for Security in Response to Threats",
draft-ietf-rserpool-threats-02 (work in progress), Sept 2003.
[8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC [8] Jungmaier, A., Rescorla, E. and M. Tuexen, "TLS over SCTP", RFC
3436, December 2002. 3436, December 2002.
Informational References (non-normative) Informational References (non-normative)
[9] Eastlake, D., Crocker, S. and J. Schiller, "Randomness [9] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
Authors' Addresses Authors' Addresses
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/