Re: Node Req. Issue 28: Security Considerations

john.loughney@nokia.com wrote:

>>>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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------