Thanks Jari, a couple of answers below. > > - explain context in which IPSec can be used to secure NDP > messages. > > This should include a reference to the SEND work. > > > > - Expand Security Considerations section to discuss more security > > threats defined in draft-ietf-send-psreq-xx.txt. > > > > - Need more elaborate discussion on manual vs. dynamic keying. > > I think the general approach is correct. You may wish to > avoid an extensive discussion of the threats and just list > the main ones, then refere to the details through psreq > (which I believe has been approved by IESG).
=> Defeinitely. That's my intention. > > Also, I think what you are trying to achieve is (a) make > it still possible to use the old AH-based approach but > explain its limitations better, (b) inform the reader about > the availability of another approach, SEND, and (c) inform the > reader about the various vulnerabilities associated with > running ND without security. This is a good approach. But > there's the additional issue of what you actually are mandating > in this document, and with what keywords. Do you have a suggestion > on what it should be? => There are two issues here: a) The current Keywords used for IPsec. They should definitely be lighter (no SHOULDs, MAY at best) or removed totally. b) What to use for SEND. I have no idea about b). As for a) I think we should remove any keywords on IPsec. I tend to think MAY is appropriate for SEND. Any ideas? > > 1. Adding a new section (3.2) before the message formats > > to briefly explain that security is outside the scope of > > this doc and refer to SEND work. It also explains when IPsec > > can be used. > > Perhaps the latter explanation could go into the security > considerations section. => ok. > How about this for 3.2: => BTW, this is section 3.3 ( a new one) sorry for the confusion. > > Vulnerabilities related to Neighbor Discovery are discussed in > Section 11.1. A general solution for securing Neighbor Discovery > is outside the scope of this specification and is discussed in > [SEND]. However, Section 11.2 explains how and under > which constraints > IPsec AH or ESP can be used to secure Neighbor Discovery. > > And then in 11.1 and 11.2 you would include text from the above. > Hesham -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
