Subject: [Hipsec] Preliminary -09

From: [email-masked] (Henderson, Thomas R)
Date: Sat Feb 7 14:39:14 2004

> -----Original Message-----
> From: Petri Jokela [mailto:[email-masked]]
> Sent: Monday, February 02, 2004 11:05 PM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: new tracker url
>=20
>=20
> > - regarding the critical parameter, what is the situation for
> > which a critical parameter is not recognized by the recipient
> > (Sec 6.2.1, page 29)?  Shouldn't this cause an increment
> > of HIP version number?
>=20
> Do you mean that introducing new critical parameters should=20
> increase the=20
> HIP version?

It seems to me that if a parameter is specified as critical,
but that the receiver doesn't recognize it and terminates
processing of the packet, then there is effectively a version
mismatch.  That is, the critical parameter bit seems redundant=20
with the version field. =20

>=20
> > - Section 8.2-- processing incoming application data.=20
> >   - first comment is that in sentence 1, it implies that IPsec
> >     SAs are selected based on IP addresses, which is not=20
> >     necessarily the case for BEET mode.
>=20
> The 2401bis defines, if I understand correctly, that the=20
> identification=20
> is based on SPIs. Shall we change the text:
>=20
> "1. Detect the proper IPsec SA using the SPI. If the resulting ..."
>=20
Fine.

Tom=20

---

From: [email-masked] (Petri Jokela)
Date: Tue Feb 10 01:34:01 2004

Henderson, Thomas R wrote:
>>Do you mean that introducing new critical parameters should 
>>increase the 
>>HIP version?
> 
> 
> mismatch.  That is, the critical parameter bit seems redundant 
> with the version field.  

Ok, but should we reserve the possibility to define new critical 
parameters without changing the HIP version number? E.g. a case when 
some hosts can use this parameter when they know that the peer 
understands it (employee traveling with his laptop and contacting the 
corporate HIP gateway). This could be some kind of policy decision on 
the end-host; do not use the critical parameter unless you talk to the 
corporate gateway. I have interpreted 6.2.2 in this way.

Another possibility is of course to explicitly say that it is not 
allowed to introduce new critical parameters unless the HIP version 
number is increased.

/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: [email-masked] (Pekka Nikander)
Date: Thu Feb 12 09:17:00 2004

>>> Do you mean that introducing new critical parameters should increase 
>>> the HIP version?
>> mismatch.  That is, the critical parameter bit seems redundant with 
>> the version field.
>

IMHO HIP version number should only be increased when introducing
a protocol change that makes all old implementations to break.
Introducing a critical parameter may or may not be such a change,
depending on where and how it is introduced.  For example, using
critical parameters could be configurable depending on the peer HI,
to be used only if the peer is known to support it.  Hence, the
"critical" bit would in this situation be more like a safeguard,
make sure that nothing bad happens in the case of misconfiguration.

It might be a good idea to clarify the draft.

--Pekka