draft-ietf-rserpool-threats-01.txt   draft-ietf-rserpool-threats-02.txt 
Internet Engineering Task Force Maureen Stillman(editor) Internet Engineering Task Force Maureen Stillman(editor)
INTERNET DRAFT Ram Gopal INTERNET DRAFT Ram Gopal
Senthil Sengodan Senthil Sengodan
Nokia Nokia
Erik Guttman Erik Guttman
Sun Microsystems Sun Microsystems
Matt Holdrege Matt Holdrege
Sonus Networks Sonus Networks
20 August 2003 15 September 2003
expires February 20, 2004 expires March 15, 2004
Threats Introduced by Rserpool and Requirements for Security Threats Introduced by Rserpool and Requirements for Security
in response to Threats in response to Threats
<draft-ietf-rserpool-threats-01.txt> <draft-ietf-rserpool-threats-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 [RFC2026]. Internet-Drafts all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts
are working documents of the Internet Engineering Task Force (IETF), are working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may also its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 2, line 25 skipping to change at page 2, line 25
2.4 PE Registration/Deregistration unauthorized . . . . . . . 5 2.4 PE Registration/Deregistration unauthorized . . . . . . . 5
2.5 Malicious ENRP server joins the group of legitimate ENRP 2.5 Malicious ENRP server joins the group of legitimate ENRP
servers . . . . . . . . . . . . . . . . . 5 servers . . . . . . . . . . . . . . . . . 5
2.6 Registration/deregistration with malicious ENRP servers . 5 2.6 Registration/deregistration with malicious ENRP servers . 5
2.7 Malicious ENRP Name Resolution .. . . . . . . . . . . . . 5 2.7 Malicious ENRP Name Resolution .. . . . . . . . . . . . . 5
2.8 Malicious node performs a replay attack.. . . . . . . . . 6 2.8 Malicious node performs a replay attack.. . . . . . . . . 6
2.9 Re-establishing PU-PE security during failover. . . . . . 6 2.9 Re-establishing PU-PE security during failover. . . . . . 6
2.10 Integrity . . . . . . . . . . . . . . . . . . . . . . . . 6 2.10 Integrity . . . . . . . . . . . . . . . . . . . . . . . . 6
2.11 Data Confidentiality . . . . . . . . . . . . . . . . . . 6 2.11 Data Confidentiality . . . . . . . . . . . . . . . . . . 6
2.12 ENRP Server Discovery . . . . . . . . . . . . . . . . . . 7 2.12 ENRP Server Discovery . . . . . . . . . . . . . . . . . . 7
2.13 Flood of endpoint unreachable messages . . . . . . . . . 7
2.14 Flood of endpoint keep alive messages . . . . . . . . . . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Intellectual Property Statement . . . . . . . . . . . . . . . . 9 7. Intellectual Property Statement . . . . . . . . . . . . . . . . 9
8. Author's addresses . . . . . . . . . . . . . . . . . . . . . . . 10 8. Author's addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
RSERPOOL provides a session layer for robustness and performance. The RSERPOOL provides a session layer for robustness and performance. The
skipping to change at page 8, line 5 skipping to change at page 7, line 38
Effect B: An ENRP server that could have been in an ENRP server pool Effect B: An ENRP server that could have been in an ENRP server pool
does not become part of a pool. A PU is unable to utilize services of does not become part of a pool. A PU is unable to utilize services of
ENRP servers. ENRP servers.
Effect C,D: This malicious ENRP would either misrepresent, ignore Effect C,D: This malicious ENRP would either misrepresent, ignore
or otherwise hide or distort information about the PE to subvert or otherwise hide or distort information about the PE to subvert
RSERPOOL operation. RSERPOOL operation.
Requirement: Discovery phase needs to be authenticated. Requirement: Discovery phase needs to be authenticated.
2.13 Flood of endpoint unreachable messages from the PU to the ENRP
server
These messages are sent by ASAP to the ENRP server when it is unable to
contact a PE. There is the potential that a PU could flood the ENRP
server intentionally or unintentionally with these messages.
Effect: DOS attack on the ENRP server
Requirement: Need to limit the number of endpoint unreachable messages
sent to the ENRP server from the PU.
2.14 Flood of endpoint keep alive messages from the ENRP server to a PE
These messages would be sent in response to a flood of endpoint
unreachable messages from the PUs to the ENRP server.
Effect: Unintentional DOS attack on the PE
Requirement: ENRP must limit the frequency of keep alive messages to a
given PE to prevent overwhelming the PE.
3. Security Considerations for Rserpool 3. Security Considerations for Rserpool
This informational document characterizes potential security threats This informational document characterizes potential security threats
targeting the Rserpool architecture. targeting the Rserpool architecture.
4. IANA Considerations 4. IANA Considerations
This document introduces no additional considerations for IANA. This document introduces no additional considerations for IANA.
5. References 5. References
skipping to change at page 8, line 32 skipping to change at page 8, line 32
Informative References: Informative References:
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996. RFC 2026, October 1996.
[RFC3365] RFC 3365, Strong Security Requirements for IETF Standard [RFC3365] RFC 3365, Strong Security Requirements for IETF Standard
Protocols, August, 2002. Protocols, August, 2002.
6. Acknowledgements 6. Acknowledgements
Thanks to the Rserpool security design team that provided valuable Thanks to the Rserpool security design team and others that provided
comments: Lyndon Ong, Randy Stewart, Qiaobing Xie, Michael Tuexen, valuable comments: Lyndon Ong, Randy Stewart, Melinda Shore, Qiaobing
Aron Silverton, Sohrab Modi, Javier Pastor-Balbas, Xingang Guo, M. Xie, Michael Tuexen, Aron Silverton, Sohrab Modi, Javier Pastor-Balbas,
Piramanayagam, Bernard Aboba and Dhooria Manoj. Xingang Guo, M. Piramanayagam, Bernard Aboba and Dhooria Manoj.
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
7. Intellectual Property Statement 7. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
skipping to change at page 10, line 5 skipping to change at page 10, line 5
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
expires 20 February 2004 expires 15 March 2004
8. Author's Addresses 8. Author's Addresses
Ram Gopal Ram Gopal
Nokia Research Center Nokia Research Center
5 Wayside Road 5 Wayside Road
Burlington, MA 01803 Burlington, MA 01803
USA USA
email: ram.gopal@nokia.com email: ram.gopal@nokia.com
 End of changes. 

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