I would support the removal of the text. These security issues really belong in the base specifications and not in an Info doc.
Regards, Brian
[EMAIL PROTECTED] wrote:
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 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
