draft-ietf-rserpool-asap-01.txt   draft-ietf-rserpool-asap-02.txt 
Network Working Group R. R. Stewart Network Working Group R. R. Stewart
INTERNET-DRAFT Cisco Systems Inc. INTERNET-DRAFT Cisco Systems Inc.
Q. Xie Q. Xie
Motorola Motorola
M. Stillman
Nokia
expires in six months November 19,2001 expires in six months March 1, 2002
Aggregate Server Access Protocol (ASAP) Aggregate Server Access Protocol (ASAP)
<draft-ietf-rserpool-asap-01.txt> <draft-ietf-rserpool-asap-02.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]. Internet-Drafts are all provisions of Section 10 of [RFC2026]. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
skipping to change at page 15, line 53 skipping to change at page 15, line 53
B) if multiple PEs exist in the pool, ASAP will choose B) if multiple PEs exist in the pool, ASAP will choose
one of them and transmit the message to it. In that case, the one of them and transmit the message to it. In that case, the
choice of the PE is made by ASAP layer of the sender based on choice of the PE is made by ASAP layer of the sender based on
the server pooling policy as discussed in section 4.5.2. the server pooling policy as discussed in section 4.5.2.
C) if no transport association exists towards the destination PE, C) if no transport association exists towards the destination PE,
ASAP will establish a new transport association, ASAP will establish a new transport association,
NOTE: if the underlying SCTP implementation supports implicit NOTE: if the underlying SCTP implementation supports implicit
association setup, this step is not needed (see [SCTP-API]). association setup, this step is not needed (see [SCTPAPI]).
D) send out the queued message(s) to the SCTP association using the D) send out the queued message(s) to the SCTP association using the
SEND primitive (see [RFC2960]), and, SEND primitive (see [RFC2960]), and,
E) if the local cache is implemented, append/update the local cache E) if the local cache is implemented, append/update the local cache
with the mapping information received in the ENRP server's with the mapping information received in the ENRP server's
response. Also, record the local SCTP association id, if a new response. Also, record the local SCTP association id, if a new
association was created. association was created.
For more on the ENRP server request procedures see [ENRP]. For more on the ENRP server request procedures see [ENRP].
skipping to change at page 24, line 19 skipping to change at page 24, line 19
max-reg-attempt - The maximum number of registration attempts to be 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.
6. Security Considerations 6. Security Considerations
To be determined. Due to varying requirements and multiple use cases of Rserpool, we
point out two basic security protocols, IPsec and TLS. We
specifically do not discuss whether one security protocol would be
preferred over the other. This choice will be made by designers
and network architects based on system requirements.
For networks that demand IPsec security, implementations MUST
support [SCTPIPSEC] which describes IPsec-SCTP. IPsec is two
layers below RSerPool. Therefore, if IPsec is used for securing
Rserpool, no 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
instead TLS, implementations MUST support TLS with SCTP as
described in [SCTPTLS] or TLS over TCP as described in [RFC2246].
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. 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.
Security support for the Rserpool end user is optional. Note that
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
user doesn't require security protection for example, against
eavesdropping for the request for pool handle resolution and
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 the requirement for security support for the ENRP server. It is
also possible for the ENRP server to reject an unsecured request
from the user due to its security policy in the case that it
requires enforcement of strong security. But this will be
determined by the security requirements of the individual network
design.
7. References 7. References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process --
3", BCP 9, RFC 2026, October 1996. Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, [RFC2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp,
T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, V. Paxson, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang,
"Stream Control Transmission Protocol," <RFC 2960>, and, V. Paxson, "Stream Control Transmission Protocol," RFC
October 2000. 2960, October 2000.
[ENRP] Q. Xie, R. R. Stewart "Endpoint Name Resolution Protocol", [ENRP] Q. Xie, R. R. Stewart "Endpoint Name Resolution Protocol",
draft-ietf-rserpool-enrp-01.txt, work in progress. draft-ietf-rserpool-enrp-02.txt, work in progress.
[SCTP-API] R. R. Stewart, Q. Xie, L Yarroll, J. Wood, K. Poon, [SCTPAPI] R. R. Stewart, Q. Xie, L Yarroll, J. Wood, K. Poon,
K. Fujita "Sockets API Extensions for SCTP", K. Fujita "Sockets API Extensions for SCTP",
draft-ietf-tsvwg-sctpsocket-01.txt, work in progress. draft-ietf-tsvwg-sctpsocket-01.txt, work in progress.
[SCTPTLS] A. Jungmaier, E. Rescorla, M. Tuexen "TLS over SCTP",
draft-ietf-tsvwg-tls-over-sctp-00.txt, work in progress.
[SCTPIPSEC] S.M. Bellovin, J. Ioannidis, A. D. Keromytis,
R.R. Stewart, "On the Use of SCTP with IPsec",
draft-ietf-ipsec-sctp-03.txt, work in progress.
[RFC2246] T. Dierks, C. Allen "The TLS Protocol - Version 1.0",
RFC 2246, January 1999.
8. Acknowledgements 8. Acknowledgements
The authors wish to thank John Loughney, Lyndon Ong, and Maureen The authors wish to thank John Loughney, Lyndon Ong, and many
Stillman and many others for their invaluable comments. others for their invaluable comments.
9. Authors' Addresses 9. Authors' Addresses
Randall R. Stewart Randall R. Stewart Phone: +1-815-477-2127
24 Burning Bush Trail. 24 Burning Bush Trail. EMail: rrs@cisco.com
Crystal Lake, IL 60012 Crystal Lake, IL 60012
USA USA
Qiaobing Xie Phone: +1-847-632-3028
Phone: +1-815-477-2127 Motorola, Inc. EMail: qxie1@email.mot.com
EMail: rrs@cisco.com 1501 W. Shure Drive, 2-F9
Qiaobing Xie
Motorola, Inc.
1501 W. Shure Drive, #2309
Arlington Heights, IL 60004 Arlington Heights, IL 60004
USA USA
Phone: +1-847-632-3028 Maureen Stillman Phone: +1 607 273 0724 62
EMail: qxie1@email.mot.com Nokia EMail: maureen.stillman@nokia.com
127 W. State Street
Ithaca, NY 14850
USA
Expires in six months from Mar. 2002
 End of changes. 

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