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
john.loughney@nokia.com 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:narten@us.ibm.com]
>>Sent: 29 September, 2003 21:36
>>To: Loughney John (NRC/Helsinki)
>>Cc: ipv6@ietf.org; jari.arkko@kolumbus.fi
>>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
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------