[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Node Req: Issue27: 11. Security Considerations



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
--------------------------------------------------------------------