Subject: RE: [Hipsec] Pre-version: ESP and Base drafts

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Mon, 16 May 2005 11:42:55 -0700

I have some comments after reviewing the esp-00 draft, please see below. I think it looks a lot better now without the conceptual packets. Petri, I'll send an xml diff of typos/minor edits separately.

- section "ESP packet processing"
"As these mechanisms can be located..." - this sentence is unclear to me, but I do not have a suggested rewrite.
- For all AES references (3 occurrences), RFC 2451 should be RFC 3602; RFC 2451 contains no mention of AES, should be removed from references
- The 64-bit sequence number is interesting, but: To implement it, you just keep an additional 32-bit counter representing the upper bits? Upon rollover of the lower 32-bits, you increment the upper. What is the usefulness of this? i.e. how can the replay window be enforced if it is not part of each packet? Maybe we could have more text on this or an appropriate reference.
- For the sentence "...exchange information about the used protocols and other...", is there another term besides "used protocols" that should be used here, such as "transforms used"?
- the key index field of the ESP_INFO parameter is mentioned for the rekeying section, but not in the preceding section when discussing the ESP_INFO.
- When talking about the IP address to HIT conversion, what about the IPv4 case? Should LSIs be mentioned also?
- In the "finalizing rekeying" section it says to use the lowest Keymat Index of the two ESP_INFO parameters, but earlier in the "transform_reply" section, is says "it is RECOMMENDED that the system use the greater value received from the peer"  ???
- It should be noted somewhere that HIP packets should bypass IPsec policies, i.e. UPDATE packet transmitted in the clear even though an active association is in place, or all protocol 99 packets bypass IPsec processing, etc.

-Jeff

> -----Original Message-----
> From: Petri Jokela [mailto:[email-masked]] 
> Sent: Friday, May 13, 2005 6:06 AM
> To: [email-masked]
> Subject: [Hipsec] Pre-version: ESP and Base drafts
> 
> 
> Folks,
> 
> Pre-versions of both the HIP ESP and Base drafts are available at
> 
> http://hip4inter.net/drafts.php
> 
> draft-ietf-hip-base-03-pre130505
> draft-ietf-hip-esp-00-pre130505
> 
> I didn't make diffs to previous versions, because the changes 
> were so big.
> 
> 
> Base draft:
> ==========
> 
> The draft has been modified quite a lot since -02, bút the changes
> are mostly related to the structure of the document. The old one was
> difficult to read and understand, and the new structure should be
> better. Thanks to Tom for the main work.
> 
> I have made some modifications to the draft based on Aura's 
> comments in
> their research paper. There haven't been too much discussion 
> on the list
> about the proposed changes. Please read and comment now:
> 
> Problem 2: the KEYMAT generation has now been modified so that I and J
> values are also included in the keying material generation. Due to
> possible rekeying, implementations must now keep the I and J values
> as long as the HIP association exists.
> 
> Problem 6: The HI encryption is now optional.
> 
> Problem 7 & 8: modifications to state machine and to packet handlings
> (processing I1 and I2 packets).
> 
> I have not yet done anything related to problems 1, 3, 4, and 
> 5. Please,
> give comments on those. Problems 3,4, and 5 seem to affect 
> the appendix
> describing puzzles.
> 
> 
> ESP draft:
> ==========
> 
> There are no conceptual packets any longer. Basic idea is now
> roughly:
> 
> 1) Create HIP association as well as ESP association during base
> exchange (ESP SA can be with NULL encryption).
> 
> This would be mandatory, and solves the problem how data packets are
> identified. In previous version when the ESP SA could be setup later,
> you couln't identify data packets after base exchange, if no 
> ESP SA was
> set up (no SPIs to look at).
> 
> 2) Use UPDATE to make ESP SA update, including change in transform
> family and rekeying.
> 
> Rekeying:
>      UPDATE(ESP_INFO, [DH])
>     ----------------------->
> 
>      UPDATE(ESP_INFO, [DH])
>     <-----------------------
> 
> Transform update
>      UPDATE(ESP_INFO, ESP_TRANSFORM, [DH])
>     --------------------------------------->
> 
>      UPDATE(ESP_INFO, ESP_TRANSFORM, [DH])
>     <---------------------------------------
> 
> And UPDATE acks naturally in both cases.
> 
> There can still be conflicting things due to big changes. Please read 
> and comment.
> 
> /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]
> https://www1.ietf.org/mailman/listinfo/hipsec
> 

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Petri Jokela <[email-masked]>
Date: Tue, 31 May 2005 16:15:27 +0300 (EEST)

I uploaded the ESP draft (snapshot + diff from previous) to:

(version dated 31.05.05)

There are three open issues at the moment in the roundup tracker

http://hip4inter.net/cgi-bin/roundup.cgi/hip-esp/index

Two of them are commented inline in the following answer. In addition to 
those, the security section is still empty.

Fixed also: timeout issue (issue #2), renumbering of ESP_INFO (issue #3), 
and ESP_INFO definition (issue #5).

On Mon, 16 May 2005, Ahrenholz, Jeffrey M wrote:

> Date: Mon, 16 May 2005 11:42:55 -0700
> From: "Ahrenholz, Jeffrey M" <[email-masked]>
> To: Petri Jokela <[email-masked]>, [email-masked]
> Subject: RE: [Hipsec] Pre-version: ESP and Base drafts
> 
> "As these mechanisms can be located..." - this sentence is unclear to 
> me, but I do not have a suggested rewrite.

I made a change to the text.
"These mechanisms can be considered to be on the network side of IPsec, 
thus they cannot add any integrity or conficentiality problems that would 
not exist without them."

Is this any better?

> - For all AES references (3 occurrences), RFC 2451 should be RFC 3602; 
> RFC 2451 contains no mention of AES, should be removed from references

Fixed.

> - The 64-bit sequence number is interesting, but: To implement it, you 
> just keep an additional 32-bit counter representing the upper bits? Upon 
> rollover of the lower 32-bits, you increment the upper. What is the 
> usefulness of this? i.e. how can the replay window be enforced if it is 
> not part of each packet? Maybe we could have more text on this or an 
> appropriate reference.

Hmm.. I'm not sure how to fix this. Earlier there was some talk about 
having AES-CBC IV vectors from the sequence number, but the RFC3602 states 
that the IV must be random.

> - For the sentence "...exchange information about the used protocols and 
> other...", is there another term besides "used protocols" that should be 
> used here, such as "transforms used"?

Fixed as proposed.

> - the key index field of the ESP_INFO parameter is mentioned for the 
> rekeying section, but not in the preceding section when discussing the 
> ESP_INFO.

I couldn't now find the place in text. Can you give a pointer to that?

> - When talking about the IP address to HIT conversion, what about the 
> IPv4 case? Should LSIs be mentioned also?

A new bullet in "Processing incoming application data":

If LSIs are used, the address field is converted to contain
the LSI value before the packet is sent to the application.

> - In the "finalizing rekeying" section it says to use the lowest Keymat 
> Index of the two ESP_INFO parameters, but earlier in the 
> "transform_reply" section, is says "it is RECOMMENDED that the system 
> use the greater value received from the peer"  ???

Fixed this. It should bet the greater of the two values.

> - It should be noted somewhere that HIP packets should bypass IPsec 
> policies, i.e. UPDATE packet transmitted in the clear even though an 
> active association is in place, or all protocol 99 packets bypass IPsec 
> processing, etc.

6. Packet processing

    Packet processing is mainly defined in the HIP base specification
    [5].  This section describes the changes and new requirements for
    packet handling when the ESP transport format is used.  Note that all
    HIP packets (currently protocol 99) MUST bypass IPsec processing.

/petri