In the IPsec section, you mention that other security issues
will be covered in the Security Considerations section, but
I don't see any issues here...
There used to be some things, but they got removed because people felt that those things belong to the individual protocol RFCs, or their future updates.
Why aren't privacy addresses covered in this document?
Should this be covered in the security section? Already, section 4.5.3 talks about privacy extensions. Do we need more?
As I mentioned, there's been a debate whether the specific issues belong here or in the individual RFCs. As John says, we already have a section for RFC 3041 and I am not aware of any specific IPv6 security issues it would raise beyond those mentioned in the document itself.
As we were working on RFC 3316 (cellular hosts), we did discuss privacy issues a little bit in the security considerations section. But there we had a reason, as we explained the specific implications and benefits (or lack thereof) of using RFC 3041 in cellular networks. As an example, since every host had its own prefix, obfuscating the interface identifier did not help quite as much as it did in Ethernet.
Here we don't have that specific situation.
Also, did you consider a recommendation that IPv6 nodes should
implement SEND? Perhaps you should at least mention the security issues with ND and indicate that the SEND group is
working to resolve them?
I believe we did not want this kind of forward reference to stuff that is on-going. However, if people feel that the SEND stuff is stable enough, we could put in a reference.
Borderline. Back in IETF-56 & 57 we believed node reqs would be done much sooner than SEND. Now in SEND we have a plan to finish all work and have the WG go to sleep; the draft will be reissued once within a couple of weeks, then reviewed, and then reissued again and sent to IESG. So it might be off to the IESG this year. Assuming I find time to edit the draft ;-)
If it gets there in time before node reqs is approved, we probably should add a reference. But it looks like we might agree about node reqs soon, so SEND probably completes slightly later. In that case there's no sense in waiting for SEND.
Anyway, that reminds me that while redoing RFC 2461, we should probably tone down the language a bit regarding the use of AH; there's widely known issues with that (send documents some of these, draft-arkko-icmpv6-ike-effects talks about others). I'm not sure we should present AH any more as general solution. Perhaps SEND is done by the time that 2461bis is ready, so it could reference some of the SEND documents. Also, I'm not sure I agree with the RFC 2460 statement that the node requirements document quotes:
The security features of IPv6 are described in the Security
Architecture for the Internet Protocol [RFC-2401].I don't agree because we appear to have a number of other security features in IPv6 in addition to IPsec. MIPv6 RR, ND options for certs and CGAs in SEND, etc.
--Jari
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
