Thomas, Your comments at the end of this mail confused me. Do you want the text removed or do you want clarifying text? The more I think about it, the more I think it would be OK to remove much of the text from the security consideration, as they really don't help the reader do anything extra. Some of the original documents need updating, so perhaps it is best left to that.
thanks John > -----Original Message----- > From: ext Thomas Narten [mailto:[EMAIL PROTECTED] > Sent: 29 September, 2003 21:36 > To: Loughney John (NRC/Helsinki) > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Node Req: Issue27: 11. Security Considerations > > > > I am not a security expert, perhaps Jari could comment on > this section. > > This document does not introduce any new security > vulnerabilites on the > > Internet. However, in creating this document some of the > contributors > > felt that there are security issues that are not covered in > existing RFCs > > and this is what we have tried to document. > > Note: I thought we were on the path that updates to the original > documents should go in those documents. So maybe at least some of the > comments could go in an appropriate revised document? And given that > at least some of them are expected to be revised, this may be > reasonable. We'd need a breakdown of which parts would go in what > document to see how this might work. > > > Perhaps you should be more specific on what should be removed, for > > example. > > the following: > > The use of ICMPv6 without IPsec can expose the nodes in question to > various kind of attacks including Denial-of-Service, Impersonation, > Man-in-the-Middle, and others. Note that only manually keyed IPsec > can protect some of the ICMPv6 messages that are related to > establishing communications. This is due to > chicken-and-egg problems > on running automated key management protocols on top of > IP. However, > manually keyed IPsec may require a large number of SAs in order to > run on a large network due to the use of many addresses > during ICMPv6 > Neighbor Discovery. > > The use of wide-area multicast communications has an increased risk > from specific security threats, compared with the same threats in > unicast [MC-THREAT]. > > An implementer should also consider the analysis of anycast > [ANYCAST]. > > > Note: to the reader who may not understand the history here, this > section just seems to have included some random things. That raises > the question of what was included and why not. At the very least, it > would make sense to include some context saying that the above is not > complete but includes some items that are discussed insufficiently in > the relevant documents. > > Thomas > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
