Subject: [Hipsec] RE: ESP draft snapshot 31.05.05

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Tue, 31 May 2005 09:21:59 -0700

Petri,
please see below...

> "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?

Yes, this is better.

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

So is there a benefit to using these 64-bit sequence numbers? Why do we
need them?

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

(using pre310505)
Section 4.1.2 Updating an Existing ESP SA  -- this mentions the keymat
index.
Section 4.1.1 Setting up an ESP Security Association -- this contains no
mention of the keymat index.
The keymat index is described in detail in 5.1.1 ESP_INFO, then for
packet processing, it is described for sections 6.8, 6.9, 6.9.1, 6.9.2,
6.9.3, 6.10,  but not in sections 6.5 and 6.6.

Section 7 Keying Material says "After the HIP association keys have been
drawn, the ESP keys are drawn..." and this is the first advice given to
the reader on what value the keymat index should have during the base
exchange.

The other various revisions noted in this email look good.

-Jeff

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

---

From: Petri Jokela <[email-masked]>
Date: Wed, 01 Jun 2005 15:17:06 +0300

> the reader on what value the keymat index should have during the base

Some fixes:

4.1.1:

"...be used by the peer host. The ESP_INFO Keymat Index value MUST be
set to zero."

6.5 (provided already by Tom):
"For this initial ESP SA establishment, the Old SPI value MUST be zero.
The Keymat Index field MUST be zero."

6.6:
"...to the peer. The ESP_INFO Keymat Index field MUST be zero."

Question: should the Keymat Index be something else than zero during the
base exchange? Basically, the Keymat Index points to the place where
keys are drawn and in _this_ specification we are defining ESP_INFO that
is used to get the ESP SA established. We are not "interested" in HIP
keys. Thus, the Keymat Index during the base exchange should point
already to the point from where the ESP keys are drawn.

Of course, keeping the Keymat Index value zero during base exchange,
does not break anything because we say that the ESP keys are drawn after
the HIP association keys.

/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]

---

From: Petri Jokela <[email-masked]>
Date: Mon, 13 Jun 2005 13:30:18 +0300

> So is there a benefit to using these 64-bit sequence numbers? Why do we

Nobody has reacted on this issue. There seems not to be need for the
64-bit sequence numbers. So, if there is no reason to keep it there I
will remove it from the next version. Comments?

/petri

---

From: George Gross <[email-masked]>
Date: Mon, 13 Jun 2005 05:07:32 -0400 (EDT)

Hi,

inline....

On Mon, 13 Jun 2005, Petri Jokela wrote:

<snip>

> will remove it from the next version. Comments?

see the draft rfc2401-bis section 4.4.2.1, now in RFC editor queue. If you
want to keep alignment with IPsec definition of a SAD, 64-bit sequence
numbers are a MUST. The intent of 64-bit sequence numbers is to handle
high volume (>Gbps) packet flows that would overwise overflow the 32 bit
sequence counter too frequently.

hth,
	George

---

From: Petri Jokela <[email-masked]>
Date: Thu, 16 Jun 2005 15:14:12 +0300

> sequence counter too frequently.

Valid point. I'll add a reference to this draft.

/petri