RE: RFC 2461- issue list

Hi,

My initial thought is also that we should not make RFC 2461bis (or
2462bis) include every extension specified since 1998.  Those can stay
very well in separate drafts.  Of course, we should still consider whether
we want to enable the base spec to give more flexibility (e.g., the
solicitation timers etc.) for those extensions.  There is a clear 
distinction between these two, IMHO.

Another thought: if we recycle RFC2461bis to DS, I think we should re-do
the implementation reports if we changed the code (not sure whether new
reports is _required_..).  This may not be a bad thing, as the current
implementation reports should (IMHO) be a bit more detailed than that..

However, there are some things which need addressing now.  Inline about 
two IMHO important classes of issues..

On Fri, 24 Oct 2003, Bound, Jim wrote:
[...]
> > Issue 3: On-link assumptions in 2461 considered harmful. 
> >          This issue was raised by Alain and documented in:
> >          draft-ietf-v6ops-onlinkassumption-00.txt
> >          draft-ietf-v6ops-v6onbydefault-00.txt
> > Also see related issue in section 2.4 of: 
> > http://www.ctie.monash.edu.au/ipv6/draft-jinchoi-ipv6-cRA-00.txt
> 
> This is nothing more than a note and should not be put into 2461.  

On the contrary, I believe this will of critical for the success of IPv6, 
and MUST BE dealt with.  Whether the WG thinks it is just enough to 
explicitly state the tradeoffs here, or whether the spec needs to be 
changed is a different subject.

> > SEND issues:
> > 
> > Issue 7: All the security discussions (e.g. assuming that AH
> >          or ESP can be added to the ND messages) will need to
> >          be put in the context of SEND. 
> > 
> > Issue 8: Security considerations section needs to consider issues
> >          in: draft-ietf-send-psreq-04
> > 
> > Issue 9: The chicken and egg problem for ND security using IKE
> >          as specified in: 
> >          draft-arkko-icmpv6-ike-effects-02 
> > 
> >          and manual SAs issues addressed in:
> >          draft-arkko-manual-icmpv6-sas-02
> 
> ND with IPsec is secure.  Mobile creates new attacks.  SEND should do
> their own spec and add value to ND.  ND should not be updated.  I argue
> and question the entire notion of SEND all the time.  Not going there
> again.  It is simply not needed for non mobile environments.

I think it may not have been clear what these issues imply.  To me, it
seems clear that we will not be creating a new "secure ND" out of
RFC2461bis.  However, now that we're identified the shortcomings of ND
from the SEND work, we MUST include (some) discussion on these subjects in
this spec.

This may also result in some changes or optional toggles to make "plain
ND" a bit more resistant to attacks, but that's not necessary as long as
the issues are documented so the implementors and the users of ND are
aware of them.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------