Subject: Re: draft-ietf-ipv6-node-requirements-01.txt

From: Richard Nelson <[email-masked]>
Date: Thu, 12 Dec 2002 17:03:05 +1100

I've read this a couple of times and I find the security section (sec 8)
quite confusing.  I am not a security expert but it appears to me that
it is not consistent.  

In particular sec 8.2 says "AH [RFC-2402] must be supported."  It then
goes on to say "there is no real need for AH" and in both section 8.1
and 8.3 there are items that "MUST be supported if AH is implemented".  
It would seem the if is redundant or something is wrong.

Equally, section 8.1 says that "IPSec tunnel mode MUST be supported" 
and then goes on to say "case .... MUST be supported if IPSec tunnel
mode is implemented."

The first paragraph of section 8.3 finishes with the sentance "Note that
the IPSec WG also recommends not using this algorithm."  It is not clear
to me which of the three algorithms mentioned in that paragraph this
sentance refers to.

It seems from section 8.3 that there are four encryption algorithms that
must be supported AES-128-CBC, HMAC-SHA-1-96, HMAC-MD5-96 and
HMAC-SHA-256.  I think this section could however be worded more
clearly.  It would also be good if the appropriate RFCs were referenced
in the text.  

From the point of view of very small devices, whilst I understand that
IPSec support is a requirement, it seems that requiring transport mode
and tunnel mode, AH and ESP and four algorithms (plus null encryption)
seems onerous.  I wasn't part of any discussion on this, but I would
appreciate it if someone would explain particularly why so many
algorithms are required.

Finally a small editorial nit.  There are lots of "is MUST"s  and few
"is SHOULD"s in the document that should be "MUST"s and "SHOULD"s.

Richard.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Mukesh Gupta <[email-masked]>
Date: Sat, 14 Dec 2002 08:31:34 -0800

Thanks for pointing this out Richard. I agree with you. I (and at least one
more guy I know) had the same confusion. We could not figure out what the
whole section meant :-(

---

From: Jari Arkko <[email-masked]>
Date: Sun, 15 Dec 2002 11:56:19 +0200

I agree with the comments. That section needs a rewrite. A couple
of points I wanted to raise, however:

- In this document, we want to describe the situation as it is in
   the other RFCs. For instance, if the IPsec RFCs say you must
   support AH and ESP then we say it here too. If the situation
   changes in the future then we we will be updating this spec.

- The same applies to algorithms as well. Someone complained about
   the many algorithms. Some algorithms (DES, MD5, SHA1) are mandated
   by the RFCs. However, in this case we have a serious problem in
   the sense that the IPsec RFCs are from some other millenium and
   the encryption algorithm choices are considered bad by the IPsec
   WG and others. I'm personally NOT going to feel very good about accepting
   a document that says you MUST use DES without even mentioning
   that its actually a bad choice. One should consider 3DES
   or AES instead. So I think we need to state something about
   those algorithms too. I wish the IPsec WG completed the AES
   spec (not sure about current status) so we could at least
   forget 3DES.

   In conclusion its not very easy to get rid of the long list
   of algorithms.

Jari

---

From: Richard Nelson <[email-masked]>
Date: Mon, 16 Dec 2002 10:04:04 +1100

Thanks for that, it certainly explains a bit.  Can I suggest that in the
re-write these considerations are made more explicit.

Richard.