RE: [rfc2461bis issue 252] Security considerations issues

[Soliman Hesham <H.Soliman at flarion.com>]

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