Subject: RE: [Hipsec] Draft: ESP usage in HIP

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 9 Feb 2005 13:10:56 -0800

Petri, thanks for producing this draft.  I have several comments:

More substantial:
- I have previously suggested not making ESP a MUST implement.  For now,
I think it can stay that way but I would like to have some further
discussion, perhaps after I submit a more lengthy draft on this topic.

- I did not find the new conceptual protocols helpful-- to me, it seems
unnecessary to add this terminology, unless you have some downstream
plan to do something different with these packet exchanges.  Wording
such as "In a typical implementation, the parameters are included in R1,
I2, and R2" seems to suggest that atypical implementations also may
exist that include these parameters in other messages, and that we
therefore have to be prepared for all possible situations, which I don't
think is what is intended.  I would suggest using the explicit R1, I2,
R2, and UPDATE names for the packets instead of HES and HER. 

- There are probably some additional things that need to be specified to
cover some cases of multihoming, but I think we will need to collaborate
a bit in the future on this point, since I don't have a concrete
proposal for you now.  For example, there are statements like (in 7.1)
"Ensure that the outgoing ESP protected packet has proper IP addresses
in its IP header" but it doesn't say explicitly how such bindings are
maintained-- maybe need a reference to the mobility draft.  

- I agree with the new ESP_INFO parameter

- Section 4.1 (Implementation options) seems misplaced, perhaps.  Maybe
as an appendix?  In any case, I don't think that the spec should
RECOMMEND how to implement (last sentence).  I would rather just see an
explanation of what has to happen to the packets.  For example, Section
3 of RFC 2406 describes ESP packet processing (both inbound and
outbound).  We should just have a similar section that points to RFC
2406 and mentions any differences in the processing.  For example,
Sections 3 and 4 (and maybe need to consider also Sections 7.1 and 7.2)
could be reoutlined as follows:
3.  Using ESP with HIP
3.1  ESP packet format
(pointer to Sec 2 of RFC 2406)
3.2  ESP packet processing
(pointer to Sec 3 of RFC 2406, explaining any diffs resulting from BEET
mode, and perhaps add the existing Sec 3.2 on SPI semantics)
3.3  Security Association establishment and maintenance
(existing Sec. 4.2-4.7)

- Section 4.6, I disagree with disallowing ESP NULL-- it may have some
operational use (maybe allow null encryption-- if both enc and auth are
null, all ESP is providing is the SPI and sequence number, and there may
be a better way to compress the HITs in such a case).

Minor:
- page 4:  s/a symmetric pair of ESP/a pair of ESP/ 

- page 6:  s/require some minor modifications in/require some minor
additions to/
  s/One new parameter is introduced for this purpose; the ESP_INFO
parameter./The ESP_INFO parameter introduced above is also used for this
purpose./

- page 6, 2nd paragraph.  I found this confusing to read at first, then
it was clearer after I read section 4.1.  Perhaps the text needs to
point forward to that.  The next-to-last sentence doesn't make sense
(the word "problems" seems misplaced).  

- page 7, s/that are conceptually included in every packet//
  s/at every given/at any given/

- page 10, s/both HITs since a/both local and remote HITs since a/

- page 10, it is not clear from reading this document whether AES and
HMAC-SHA-1-96 should be offered in the R1, or whether they are implicit
and do not ever need to be offered as possible transforms.

- page 11, s/that have been authenticated//
  s/conseptual/conceptual

- page 18, s/ones carrying a HER1 information/ones carrying HER1
information/

- page 19, s/MAY responder, rate limited,/MAY respond (subject to rate
limiting the responses)/

- page 20, sections 7.1 and 7.2 might need some similar reference to
2401bis for how to do security association lookup?

- page 21, s/piggypacked/piggybacked/ 

> -----Original Message-----
> From: Petri Jokela [mailto:[email-masked]] 
> Sent: Thursday, February 03, 2005 2:55 AM
> To: [email-masked]
> Subject: [Hipsec] Draft: ESP usage in HIP
> 
> Folks,
> 
> The ESP text is moved now from the Base specification into a 
> new draft. 
> The preliminary version 1 of this draft is available at:
> 
> http://www.hip4inter.net/drafts.php
> 
> Some notes:
> 
> The ESP setup and rekeying processes are defined as 
> conceptual protocols HIP ESP Setup (HES) and HIP ESP Rekeying 
> (HER). In a usual implementation, the contents of these 
> packets is put in base exchange packets and UPDATEs, respectively.
> 
> The NES and SPI are proposed to be replaced with a single parameter: 
> ESP_INFO.
> 
> Comments are appreciated. The intention is to make fixes 
> during next week and submit the draft before the IETF 
> deadline for -00 drafts (Feb 14)
> 
> BR, Petri
> 
> -- 
> Petri Jokela                        Tel:    +358 9 299 2413
> Research scientist                  Fax:    +358 9 299 3535
> NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
> Oy L M Ericsson Ab                  email: [email-masked]
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> http://honor.trusecure.com/mailman/listinfo/hipsec
> 
> 
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Petri Jokela <[email-masked]>
Date: Thu, 10 Feb 2005 18:43:40 +0200 (EET)

> discussion, perhaps after I submit a more lengthy draft on this topic.

Ok. We leave it as it is (for the time being).

> R2, and UPDATE names for the packets instead of HES and HER.

The idea was that we do not bind the required information exchange to 
these particular HIP packets. Perhaps we could set up the ESP Security 
Association afterwards using UPDATE messages. I must admit that I have a 
similar feeling that the current text is not very reader friendly.

I am not going to change this before the initial submission (Friday), but 
I would like to hear more comments on this. Based on the discussion, 
changes can be made to the next version of the draft.

> maintained-- maybe need a reference to the mobility draft.

Ok. I'll see the text tomorrow, but I suppose all changes go to the next 
version and we can discuss them later.

> - I agree with the new ESP_INFO parameter

Ok.

> 3.3  Security Association establishment and maintenance

I'll come up with a proposal before next draft. I have only one day to fix 
the draft before my submission deadline.

> be a better way to compress the HITs in such a case).

I read 4.6 so that it is not illegal to use ESP NULL, but you have to 
configure it separately. In this case, data would "never" be in the 
network unprotected, unless you explicitly allow the host to do so. I 
would stick with the current text. Any opinions? Clarifications / changes 
needed to the text?

BR, Petri

---

From: Petri Jokela <[email-masked]>
Date: Fri, 11 Feb 2005 15:00:23 +0200

Hi!

I submitted the ESP draft to IETF. The document can also be found from:

I didn't have time to make any big changes base on Tom's comments. I 
made only one change in the text in addition to the typo fixes.

> and do not ever need to be offered as possible transforms.

I changed this a bit to make it mandatory to include the transport in 
the packet. Otherwise the negotiation is cancelled. Any opinions?

"All HIP implementations MUST support AES [3] and HMAC-SHA-1-96 [2].
  If the Initiator does not support any of the transforms offered by
  the Responder in the R1 HIP packet, it should abandon the negotiation
  and inform peer with a NOTIFY message about a non-supported transform."

BR, Petri

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 11 Feb 2005 18:49:00 +0200

>  and inform peer with a NOTIFY message about a non-supported 

Looks good other than that the NOTIFY packet is unnecessary.  The 
responder
doesn't have any state; it will simply ignore the NOTIFY.  Having
it to process an unprotected NOTIFY and change its policy would pose
a security risk.

In general, if the responder and initiator policies are incompatible,
there is nothing one can do.  The responder won't even know, unless
the initiator completes the base exchange (without ESP) and THEN sends
a NOTIFY.

--Pekka