Subject: Re: [Hipsec] WGLC: draft-ietf-hip-rfc5202-bis

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 11 Mar 2013 14:57:05 -0700

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.

---

From: Petri Jokela <[email-masked]>
Date: Tue, 26 Mar 2013 13:18:11 +0200

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

> 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 proces…

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…

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…

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-…

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?

> Do we want to reference the tunneling of ESP over UDP?

Here I cannot say anything. Any opinions from others?

> 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-masked]
Mobile: +358 44 299 2413

---

From: Miika Komu <[email-masked]>
Date: Tue, 26 Mar 2013 15:44:21 +0200

Hi,

> Here I cannot say anything. Any opinions from others?

how are the RFCs bundled together for the standards track, or would this 
create an undesired dependencies? If it creates such a dependency, can 
it be avoided by referencing NAT specification as informational?

---

From: Ari Keränen <[email-masked]>
Date: Thu, 28 Mar 2013 21:22:40 +0200

Hi,

> it be avoided by referencing NAT specification as informational?

I think mentioning this possibility could make sense since "HIP doesn't 
work through NATs" seems to be one of the biggest misconceptions people 
have had about HIP. However, I don't see any reason why it should be a 
normative reference, so informative (and hence not blocking) would be fine.

Cheers,
Ari

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 28 Mar 2013 13:25:57 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ari Keränen
> Sent: Thursday, March 28, 2013 12:23 PM
> To: Miika Komu
> Cc: HIP
> Subject: Re: [Hipsec] WGLC: draft-ietf-hip-rfc5202-bis
> 
> Hi,
> 
> > how are the RFCs bundled together for the standards track, or would
> > this create an undesired dependencies? If it creates such a
> > dependency, can it be avoided by referencing NAT specification as
> informational?
> 

It could be done with reference to published RFCs, just to declare that it is out of scope of this document and handled elsewhere.

e.g. something like this at the end of Introduction, with two informative references.

"HIP and ESP traffic have known issues with middlebox traversal [RFC5207].  Other specifications exist for operating HIP and ESP over UDP ([RFC5770] is an experimental specification, and others are being developed).  Middlebox traversal is out of scope for this document."