Hello,SECDIR and Shunsuke Suzuki pointed out that we did not sufficiently describe security influence this requirement might be brought.
For this issue, I would like to put these words in the section 3 (security consideration part). Please check this, all of you. Thanks for advance.
--------------------There are some security incidents when combining these requirements described in Section 2 into a protocol. Particulars are listed in the below. a. keep data confident and having data protected for avoidance of Denial Service Attack at node or network caused by unsafe and tampered data. b. detect a certified information resource(s) and keep communication with confidential information resource(s). This is for avoidance of hijacking or tapping from unsafe node. c. keep network availability at a estimated level. This is for avoidance of Denial of Service Attack for network resources. d. keep service availability in a specific node at an estimated level. This is for Avoidance of Denial of Service Attack for node/ computer resources. e. keep an estimated administrative, controlled level in the whole network. This is for avoidance of intrusion of security boundary caused by malicious use of multiprefix environment. This is also for avoidance of leakage of some information from central controller.
All the way listed below should be well-considered for the protection from security threats. There is no necessity to comply with all items at same time, and it will be accepted if one or more spec will come to apply the other spec. The network operational spec will be considered and described as what and how it works for the network security. It is also preferable to refer and use existing technologies. A. consideration of use of necessity for digitally-signed or cryptographic message
B. consideration of use of necessity for confidence of data source C. consideration of use of necessity for authenticationD. consideration of use of necessity for validation mechanism for both of nodes and messages E. consideration of use of necessity for avoidance mechanism of data conflict F. consideration of use of necessity for appropriate filtering method at domain boundaries G. consideration of use of necessity for data independence method at node or an interface. H. consideration of use of necessity for information control mechanism at server if a node gets information from outside of its network domain.
Here is a list for estimation of the impact to security incidents that the requirements in this document may interfere.
2-1: Effectiveness will have no impact to security issues 2-2: Timing will have no impact to security issues2-3: Dynamic update has a possibility if it is maliciously used to lead high load average for network and machine resources. This may become a Denial of Service attack. Safe protocol should be used.
2-4: Node-Specific behavior has a possibility to take attacks to a specific node. Authorization and validation will protect this.
2-5: Application specific behavior will have no impact to security issues
2-6: Multiple interfaces has a possibility to take denial of service to machine resources. It also has a possibility of becoming a steppingstone beyond security boundary. It is necessary to have a filtering mechanism at domain boundary and independence between interfaces. It is desirable to have some protection by a protocol or operation.
2-7: Central control mechanism has a possibility to take session hijack attacks if the central controller is unsafe and gives invalid information to nodes. Information should be managed. Protocol should have a mechanism for validation, confidence, authentication, authorization.
2-8: Next-hop selection has a possibility to take denial of service due to a conflict between routing system and policy table. If a routing system has own security mechanism, it is necessary to cooperate with it, not interfere the mechanism.
-------------------- On 2007/07/13, at 18:38, Julien Laganier wrote:
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Background: In multi-prefix environments it is possible for an IPv6 node to have multiple IPv6 addresses available. There is thus a need to select appropriate source and destination addresses when initiating communication. RFC3484 defines default address selection for IPv6. Another v6ops draft [I-D.ietf-v6ops-addr-select-ps] points to some situations in which RFC3484 leads to problems, hence the desire to introduce new selection mechanisms overcoming those. This document discusses requirements for such mechanisms. Security Review: While I think this is useful work, I am concerned that security wasn't made a requirement in itself and is instead just touched upon in the security considerations section. I also think that the security considerations section is not appropriate: it doesn't do a good job of analyzing threats that might be introduced by address selection mechanisms. It is insufficient to state that "incorrect address selection can lead to serious security problems, such as session hijack", this is too vague. Security threats should be listed exhaustively. As I already said, I believe that it should be made a requirement in itself that these threats are appropriately countered. Since it also seems that address selection mechanisms can be realized via protocols, it might also be good to go into what are the requirements on protection of these protocols (e.g. network filtering at the domain boundary, message authentication, etc.). Non-security nit: In section 2.5., "address selection API" could reference a recently approved individual submission [I-D.chakrabarti-ipv6-addrselect-api]. Hope that helps. Best regards, --julien
------------------------------- Ruri Hiromi hiromi@inetcore.com
Attachment:
smime.p7s
Description: S/MIME cryptographic signature