Subject: Node Req: Issue27: 11. Security Considerations

From: [email-masked]
Date: Wed, 24 Sep 2003 15:13:22 +0300

> > 11. Security Considerations
> 
> This section seems both too detailed and not detailed enough. Too
> detailed in that it talks about security issues related to some
> (arbitrary?) protocols like ICMPv6, but not detailed enough in that it
> is anywhere complete and doesn't mention many other protocols that
> could also be included if one were to include ICMPv6. My suggestion
> would be to up-level here and not talk about detailed security issues
> of individual protocols. If you want to do that, point to the security
> sections in other documents. But if you do this, you'll have a hard
> time deciding whether to mention every document or just some.
> 
> Does _this_ document itself introduce or raise any security issues not
> covered elsewhere? That is the question this document should focus
> on. The answer may be mostly no.

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.  Perhaps you should be more
specific on what should be removed, for example.

John

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Thomas Narten <[email-masked]>
Date: Mon, 29 Sep 2003 14:35:42 -0400

> 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