draft-ietf-rserpool-enrp-01.txt   draft-ietf-rserpool-enrp-02.txt 
Network Working Group Q. Xie Network Working Group Q. Xie
INTERNET-DRAFT Motorola INTERNET-DRAFT Motorola
R. R. Stewart R. R. Stewart
Cisco Systems Cisco Systems
M. Stillman
Nokia
Expires in six months Nov. 20, 2001 Expires in six months March 1, 2002
Endpoint Name Resolution Protocol (ENRP) Endpoint Name Resolution Protocol (ENRP)
<draft-ietf-rserpool-enrp-01.txt> <draft-ietf-rserpool-enrp-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 RFC 2026. Internet-Drafts are all provisions of Section 10 of RFC 2026. 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 20, line 35 skipping to change at page 20, line 35
<MAX-TIME-NO-RESPONSE> - pre-set threshold for how long a message <MAX-TIME-NO-RESPONSE> - pre-set threshold for how long a message
sender will wait for a response after sender will wait for a response after
sending out a message. (Default=5 secs.) sending out a message. (Default=5 secs.)
<TIMEOUT-SERVER-HUNT> - pre-set threshold for how long a sender <TIMEOUT-SERVER-HUNT> - pre-set threshold for how long a sender
will wait before sending another will wait before sending another
SERVER_HUNT message out. (Default=5 secs.) SERVER_HUNT message out. (Default=5 secs.)
6. Security COnsiderations 6. Security COnsiderations
[TBD] 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 -- Revision
3", BCP 9, RFC 2026, October 1996. 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.
[ASAP] R. R. Stewart, Q. Xie: "Aggregate Server Access Protocol [ASAP] R. R. Stewart, Q. Xie: "Aggregate Server Access Protocol
skipping to change at page 21, line 10 skipping to change at page 21, line 10
[RSERPOOL2] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore, [RSERPOOL2] M. Tuexen, Q. Xie, R. R. Stewart, E. Lear, M. Shore,
L. Ong, J. Loughney, M. Stillman: "Architecture for Reliable Server L. Ong, J. Loughney, M. Stillman: "Architecture for Reliable Server
Pooling," <draft-ietf-rserpool-arch-00.txt>, work in progress. Pooling," <draft-ietf-rserpool-arch-00.txt>, work in progress.
[RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp,
H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and,
V. Paxson: "Stream Control Transmission Protocol," RFC 2960, October V. Paxson: "Stream Control Transmission Protocol," RFC 2960, October
2000. 2000.
[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 Qiaobing Xie Phone: +1-847-632-3028
24 Burning Bush Trail. Motorola, Inc. EMail: qxie1@email.mot.com
Crystal Lake, IL 60012 1501 W. Shure Drive, 2-F9
Arlington Heights, IL 60004
USA USA
Phone: +1-815-477-2127 Randall R. Stewart Phone: +1-815-477-2127
EMail: rrs@cisco.com 24 Burning Bush Trail. EMail: rrs@cisco.com
Crystal Lake, IL 60012
Qiaobing Xie
Motorola, Inc.
1501 W. Shure Drive, #2309
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 Nov. 2001 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/