Subject: RE: [Hipsec] Packet reordering, certificates and base exchange

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 20 Jun 2005 10:14:13 -0700

> -----Original Message-----
> From: Teemu Koponen [mailto:[email-masked]] 
> Sent: Thursday, June 16, 2005 12:45 PM
> To: [email-masked]
> Subject: [Hipsec] Packet reordering, certificates and base exchange
> 
> All,
> 
> The latest base-03-pre defines a control bit for both I2 and R2 to 
> inform a peer to wait for shortly arriving certificate packets. 
> However, I did not find any discussion how the peer should 
> behave if a 
> certificate packet arrives before I2/R2. Packet reordering is not 
> anything rare in Internet, so it should be considered.
> 
>  From initiator's point of view, I think it just means that the 
> responder's certificate packets should be cached for a short 
> period of 
> time. Someone else probably has a better understanding of the 
> required 
> time window, so I do not even try suggest any practical time. :-)
> 
> However, introducing caching in responder is not an option due to the 
> fact that it should remain stateless until it receives I2. As the 
> initiator cannot enforce the I2 to arrive before the certificates, 
> without a significant delay between I2 and certificate packets, I 
> wonder if it might make sense to alter the I2 to optionally contain a 
> number of certificate parameters. Then, initiator could actually send 
> multiple I2s, each containing a different certificate, or a single I2 
> that possibly gets fragmented. If R2 gets the same enhancement, the 
> certificate packet eventually becomes useless, I think.
> 
> Comments?
> 

I think it makes sense to add capability to include certificates in the
base exchange packets.  I'm not that sure it makes the utility of
stand-alone CER packets go away, though.

However, I would suggest that such a topic (using HIP with certificate
infrastructure) could be separate work item for future, and not try to
fix the base spec now with little experience on the approach.  For that
matter, I would probably be more in favor of taking out CER from the
existing base spec rather than trying to improve its definition at this
time.

Tom

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

---

From: Teemu Koponen <[email-masked]>
Date: Tue, 21 Jun 2005 13:06:56 -0700

On Jun 20, 2005, at 10:14, Henderson, Thomas R wrote:

Tom,

> stand-alone CER packets go away, though.

If CER packet was removed, all other packets should be able to carry 
CER parameter then I think.

> existing base spec rather than trying to improve its definition at this

I agree, CER should be removed from the base specification. IMHO the 
current approach is anyway broken and thus requires further 
consideration.

Teemu

--

---

From: Petri Jokela <[email-masked]>
Date: Tue, 21 Jun 2005 23:10:27 +0300 (EEST)

> existing base spec rather than trying to improve its definition at this

We have now three options:

1) Try to fix the CER packet in base spec
2) Take it out and submit as a separate draft
3) Leave it as it is now

1) firstly, we should identify all the possibilities to fix the problem 
(some proposals exists) and secondly, validate the solutions. This 
requires time, and I think that we should avoid spending too much time on 
fixing things now.

2) is a quite easy-to-do procedure (at least removing it from the base 
specification).

3) is not an option, because the CER system is now broken.

>From 1) and 2), I would vote for 2).

/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: Pekka Nikander <[email-masked]>
Date: Wed, 22 Jun 2005 09:15:19 +0300

> 2) Take it out and submit as a separate draft

I think 2) is the best way to go now.  I would go even a little bit 
further
and merely define a code point (parameter type) for the certificate 
parameter,
and state that the exact syntax, semantics, and use are to be defined 
elsewhere.

That is, IMHO, we should include some text about certificates in the 
base
spec lest the SEC ADs come to us and ask about this.  If it is clear 
from
the text that we have considered the situation and decided to leave it 
for
later, that should be fine.

Chairs, if the WG decided to take this way, it would be good to consider
another milestone for the certificate spec.

--Pekka

---

From: Petri Jokela <[email-masked]>
Date: Wed, 22 Jun 2005 16:00:18 +0300

Pekka Nikander wrote:
> I think 2) is the best way to go now.  I would go even a little bit further

I admit that I haven't waited too long time after these comments, but I
edited the draft and took certificates out. I left the CERT type
definition and a short piece of text. The current pre version is
available at

http://hip4inter.net/drafts.php

dated 220605. However, if there comes still need for the certificates in
the base spec, it is not a big effort to put them back.

/petri

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 22 Jun 2005 16:06:36 +0300

> the base spec, it is not a big effort to put them back.

Ref [16] (X.509) seems to be a leftover from this change.

--Pekka

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 27 Jun 2005 15:53:53 +0300

Hi,

> another milestone for the certificate spec.

yes, we would need to do that.

In any case, our focus should still be on requesting the publication of 
the base and the ESP specs right after Paris. This means that we have a 
very tight deadline.

Thanks,

Gonzalo