Subject: [Hipsec] HIP questions regarding TCP and HITs/LSIs

From: [email-masked] (Henderson, Thomas R)
Date: Wed Mar 17 14:53:00 2004

> -----Original Message-----
> From: Tim Shepard [mailto:[email-masked]]=20
> Sent: Wednesday, March 17, 2004 12:08 PM
> To: Stephen Sprunk
> Cc: [email-masked]
> Subject: Re: [Hipsec] HIP questions regarding TCP and HITs/LSIs=20
>=20
> I'm not sure any of those implementing HIP takes the type 2 HITs
> seriously.  (Maybe someone does, but last I knew, noone was planning
> on implementing them.)
>=20
> I suggested that the type 2 HIT stuff be removed from the draft a year
> or so ago (in conversation).
>=20

I've been considering whether we want to define type 2 HITs such that=20
some kind of structure or hierarchy can be embedded in the high order=20
bits, for help with reverse lookups.  Specifically, I have DNS in mind,
and perhaps Bob or others did when they defined type 2.  This I view as=20
a research issue, so if we remove the type 2 HITs from the base draft=20
for now, let's do so in a way that doesn't preclude adding them back=20
in later.

Tom

---

From: [email-masked] (Stephen Sprunk)
Date: Wed Mar 17 16:37:01 2004

Thus spake "Henderson, Thomas R" <[email-masked]>
> > From: Tim Shepard [mailto:[email-masked]]
> >
> I've been considering whether we want to define type 2 HITs such that
> some kind of structure or hierarchy can be embedded in the high order
> and perhaps Bob or others did when they defined type 2.  This I view as
> a research issue, so if we remove the type 2 HITs from the base draft
> for now, let's do so in a way that doesn't preclude adding them back
> in later.

The exact wording for this depends on whether HITs are part of the IPv6
address space or a different (colliding) 128-bit address space.

The main issue the base draft will need to cover in either case is what a
host should do when encountering an HIT from part of the address space it
doesn't implement.  Perhaps mandate that all hosts have at least one type 1
HIT available for fallback if its preferred type is refused by the remote
host?

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin

---

From: [email-masked] (Petri Jokela)
Date: Thu Mar 18 07:05:03 2004

> HIT available for fallback if its preferred type is refused by the remote

The HIP base draft touches the type 2 HITs only in section 3, pointing 
to the dns-draft that would define the HAA and hash in type 2 case. Will 
the coming DNS draft include this definition? If yes, should we leave 
the type 2 there as it is now? If no, shall we remove all references to 
type 2 and just say that "Other types of HITs can be defined in separate 
documents.".

Another thing is, as Stephen proposes, shall we make type 1 HITs 
mandatory? At the moment, they implicitly are mandatory as there is no 
other type defined.

/petri