Jari,
> >>>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.
Agreed. No changes needed in current doc.
> >>>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.
Agreed.
> >>>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.
Agreed.
> 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.
Suggested re-write:
Many of the the security features of IPv6 are described in the Security
Architecture for the Internet Protocol [RFC-2401].
However, your above text seems to indicate that 2401 requires a substantial
re-write.
John
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
