This is a WGLC review of RFC5202-bis. This draft seems to be close to being ready. There are two areas (more detail below) that IMO could be clarified or else left out of scope:
1) handling of simultaneous IPsec and HIP ESP 2) multiple SAs for differentiated services 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? 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. 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? 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. 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). Section 5.2.1.1 should replace HMAC-SHA1 with HMAC-SHA256. The same change should be made in 5.2.1.2. Section 6 should update the HIP protocol number to 139 (from 253). Do we want to reference the tunneling of ESP over UDP? 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. _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
