Subject: RE: [rfc2461bis issue 252] Security considerations issues

From: Soliman Hesham <[email-masked]>
Date: Wed, 11 Feb 2004 04:25:59 -0500

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

---

From: "James Kempf" <[email-masked]>
Date: Wed, 11 Feb 2004 08:57:18 -0800

> any keywords on IPsec. I tend to think MAY is appropriate

I think we need to ask the Security ADs about this. Of the drafts I've seen,
security is a MUST in standards track drafts, otherwise, there's a risk that
the standard is recommending something lax and subject to attack.

            jak