Subject: [MSEC] Re: [saag] I-D ACTION:draft-bellovin-useipsec-04.txt (Forwarded)

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 22 Sep 2005 15:09:35 -0700

Note:  This document is also in IETF last call, so I am cc'ing the 
IESG.  Someone might choose to delete them from the cc list if a long 
discussion follows.

Summary:  I read the 00 or 01 of this document, and hoped that it will be 
revised and brought up to date before being published as an RFC.  As is 
stands now, it will be published in early 2006, already outdated and not as 
useful as it might be if revised to reflect the issues in choosing IPsecbis 
and IKEv2.  Furthermore, many new standards proposals in the IETF and in 
other SDOs are already using IKEv2 and IPsecbis, so this BCP, if published 
as is sends mixed messages.  Finally, the text on the use of IPsec for 
multicast security is at odds with several years worth of completed and 
ongoing work in the MSEC WG.

Review:

"Let's use IPsec (2401bis etc) and IKEv2" is what IETF WGs and other SDOs 
say nowadays.   An entire working group (MOBIKE), at least one work item in 
the MIP6 WG (e.g., 
http://ietfreport.isoc.org/all-ids/draft-ietf-mip6-ikev2-ipsec-03.txt) and 
some work in 3GPP2 are examples of this.  I recently started a couple of 
discussions in the IPSEC list asking questions that arose while working on 
3GPP2 contributions, and the discussions centered around strict compliance 
with 2401bis and IKEv2 (as well they should; however, there are some 
conflicts in requirements between those two documents and there is the 
ikev2-clarifications document to address that, but I digress).

Tone of the document
--------------------------
The useipsec I-D takes the tone of not all required features in the 
specifications are supported in implementations so new RFC authors might 
want to take note of that: practical advice, but I think also a slippery 
slope to normalize implementations that might have been centered around a 
specific use case -- e.g., VPNs.  Other use cases -- some in discussion now 
and others yet to be conceived -- may require features that are in the 
specs as RECOMMENDED or even MUST, but are not necessarily available in all 
implementations.  (Please see Section 8, item (h)).  The IETF's advice 
should be along the lines of what's in the specs and not what is widely 
implemented.  If there is consensus that what's implemented is all that is 
needed and the original specifications are overdone, well we should revise 
the specs (e.g., we do that, as in case of IKE to IKEv2).

New protocols vs. Old protocols
--------------------------------------
To come back to the issue of IKE+IPsec vs. IKEv2+IPsecbis:  I think the BCP 
should talk about IKEv2 and IPsecbis and make some passing references to 
IKE and IPsec in historical notes.  I realize IKEv2 and IPsecbis are in 
infancy w.r.t. implementation and deployment, but we should encourage 
future specification writers, whether in the IETF or other SDOs, to use 
IKEv2 and IPsecbis and not the older versions (as I note above, people are 
already using IKEv2 and IPsecbis, and so the IETF publishing a BCP 
referring to protocols that are ready to be phased out sends a mixed message).

Some specific changes along those lines would be in Sections 6 (e.g., there 
are new selectors and databases in IPsecbis to consider now) and 8 (No more 
main and aggressive modes, please :-)).  In Section 8, I would delete (h).

Section 7, Multicast related text
------------------------------------------
Next, I think Section 7 needs to be updated and references to Transport 
mode need to be updated with point to multi-point use (perhaps end-to-end 
is a more generic and all encompassing term to use with transport 
mode).  Section 7 notes that there are no key management protocols for the 
general case:  the MSEC group developed, not one but two (MIKEY, which is 
referred to, was also an MSEC product, but has nothing to do with IPsec) 
group key management protocols: GDOI specified in RFC 3547 is quite similar 
to IKEv1 and is a general purpose group key management protocol; similarly 
GSAKMP is also a general purpose key management protocol, and is currently 
in the RFC Editor queue.  While I agree that replay protection is 
important, it is after all OPTIONAL in IPsec specifications and so was not 
a priority for MSEC.  Multi-sender replay protection is indeed a hard 
problem and someone -- Sandy Harris@Paris -- noted that it has come up in 
RPSEC recently, and so MSEC agreed to try and look at the problem 
again.  GDOI and GSAKMP work very well with IPsec and other security 
encapsulation protocols and so the BCP should not be saying that it is 
inappropriate to use IPsec for multicast traffic.  In fact, there is a 
msec-ipsec-extensions document which is specifying multicast and group 
security extensions to IPsec.  The multicast portions of the current 
IPsecbis document were written after a good amount of discussion with a 
team of MSEC contributors.

Some nits:

Old
Authors of RFCs that rely on IPsec must specify the following:
New
Authors of standards documents that rely on IPsec must specify the following

In Section 4
Old
RFC2041
New
RFC2401

In Section 8
Old
RFC2284
New
RFC3748

regards,
Lakshminath

At 05:22 PM 9/19/2005, Steven M. Bellovin wrote:

>------- Forwarded Message
>
>
>To: [email-masked]
>From: [email-masked]
>Message-Id: <[email-masked]>
>Date: Mon, 19 Sep 2005 10:50:02 -0400
>
>
>- --NextPart
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : Guidelines for Mandating the Use of IPsec
>         Author(s)       : S. Bellovin
>         Filename        : draft-bellovin-useipsec-04.txt
>         Pages           : 13
>         Date            : 2005-9-19
>
>The Security Considerations sections of many Internet Drafts say, in
>    effect, "just use IPsec".  While this is sometimes correct, more
>    often it will leave users without real, interoperable security
>    mechanisms.  This memo offers some guidance on when IPsec should and
>    should not be specified.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-bellovin-useipsec-04.txt
>
>
>
>                 --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
>
>
>_______________________________________________
>saag mailing list
>[email-masked]
>https://jis.mit.edu/mailman/listinfo/saag

_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec