Hi, Comments and questions follow. If I haven't commented, I have just changed it in the draft.
The current version can be found from: http://jokela.org/ietf/draft-ietf-hip-rfc5202-bis-02-pre1.txt > The supported transforms listed in Section 3.3.5 are out of date. The title > could be changed to "Supported Ciphers" to match the renaming of > HIP_TRANSFORM to HIP_CIPHER in RFC5201-bis. SHA1 should be replaced with > AES-256-CBC (see section 5.2.8 of RFC 5201-bis). > > Section 3.3.5, ESP NULL encryption should be paired with SHA-256 instead of > SHA-1. > > Section 3.3.7, why is a value of 15 minutes specified for default inactivity > timeout of 15 minutes? Could we instead avoid a magic number here and state > that an implementation SHOULD support a configurable SA timeout value? > > Section 3.4, third paragraph. I don't know the basis for the assertion that > HIP SA processing takes place always before the IPsec processing. Isn't this > implementation dependent? What HIP processing is being referred to here, > pseudo-header manipulation, or more? Can we delete this paragraph, or > otherwise clarify? I think there was a reason to do this, but I have no idea what it was. Does it make any sense, or shall we delete it? > Section 5.1: According to Section 5.2 of RFC 5201-bis, the HIP parameter > type code range devoted to transform-specific parameters is 2048-4095, so the > values of 65 and 4095 should be reconsidered (what might be better values in > the allowed range?). Also, from an editorial perspective, the last sentence > regarding NOTIFY should follow the table of two ESP transport parameters. Should the first value be from the beginning of the area and the second one from somewhere in the middle? I don't know if it does matter, but originally they were selected with that principle. So, 2049 and 3072 perhaps? I moved the last sentence to follow the table. > > In section 5.1.1, the second paragraph states that setting up of multiple SAs > for multihoming is out of scope. However, the next paragraph discusses the > setting of multiple SAs for differentiated services. It seems to me that > this is underspecified, particularly how the coordination of selectors > between hosts is done and how to manage the KEYMAT and expiry/renewal of > multiple SAs. Should this be removed for now and left for further study? I removed the paragraph. > Section 5.1.2 crypto choices need alignment with current RFC5201-bis. Value > 2 (3DES) should be deprecated. Value 5 should probably be deprecated. All > references to HMAC-SHA-2 should be HMAC-SHA-256. Should HMAC-SHA-384 > variants be encoded? The two mandatory implementations should be the SHA256 > variants. Listed the following as mandatory: Mandatory implementations: AES-128-CBC with HMAC-SHA-256 and NULL with HMAC-SHA-256. > > Throughout Section 5.1, the draft should be updated to substitute > NOTIFICATION for NOTIFY when referring to the parameter (this is to align > with a change in RFC5201-bis). I hope I changed them correctly everywhere. > > Section 5.2.1.1 should replace HMAC-SHA1 with HMAC-SHA256. The same change > should be made in 5.2.1.2. Changed now to AES-128-CBC + HMAC-SHA-256. Or should it be AES-256-CBC? > > Section 6 should update the HIP protocol number to 139 (from 253). > > Do we want to reference the tunneling of ESP over UDP? Here I cannot say anything. Any opinions from others? > > Nits: > section 3, "new" is misspelled as "npew". Perhaps the word "new" is > unnecessary here and later in this paragraph. > > Section 3.2 probably should be clarified (qualified) that a standards > compliant, unmodified IPsec implementation can be used "in conjunction with > some additional transport checksum processing above it, and if IP addresses > are used as indexes to the right host context". > > Section 3.3.4, "IKE" is used for the first time without expansion, and > without reference to the RFC. Also, change "partner" to "peer" in the next > sentence. > > Section 5.1.1, the first sentence is duplicated. Petri -- Petri Jokela Senior researcher NomadicLab, Ericsson Research Oy L M Ericsson Ab E-mail: [email protected] Mobile: +358 44 299 2413 _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
