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

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

My apologies if this has already been covered, but I'm still working my way
through the archives...

Obviously, in the case where the host requires HIP, the TCP handshake is
delayed until HIP establishes an SA.  How should hosts handle the case where
local policy is to attempt HIP on all connections (inbound and/or outbound)
but not require it?  It seems that, to avoid the R1 timeout when the remote
host doesn't support HIP, the host should start (or respond to) a TCP
handshake immediately while starting the HIP base exchange in parallel and
begin encapsulating that session in ESP once an SA is available (if ever).
Presumably this wouldn't cause problems for NATs or firewalls because the
HIP session would create viable new state and the unprotected TCP session's
state would time out.

I'm also confused about where LSIs and HITs are visible to applications;
this doesn't seem clear in the draft (to me).  Would these be the local and
remote addresses of a socket returned by API calls?  If that's correct,
presumably an LSI would be returned to IPv4-only API calls and an HIT would
be returned to IPv6-aware calls.  Since HITs may collide with valid IPv6
addresses, would they have a different AF_* number?  Is an HIT or LSI a
valid source and/or destination address when creating a new socket?

This also makes me wonder how an application is expected to handle the case
where the local and/or remote "address" changes (to an LSI or HIT) from what
is specified before the connection is started, possibly even well after the
connection is completed (presumably as late as the R1+R2 timeouts).

Last, the draft specifies 1.0.0.0/8 as the prefix for LSIs; has this been
allocated by IANA for the purpose or should this really be TBD?  I'm
wondering if a similar allocation from the IPv6 address space should also be
done to use for HITs if they're not otherwise distinguishable from IPv6
addresses.

Thanks.

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] (Tim Shepard)
Date: Wed Mar 17 02:31:01 2004

> done to use for HITs if they're not otherwise distinguishable from IPv6

No such assignment has been made by IANA. (The official status of IANA
IPv4 address space allocations (of /8 prefixes) can be seen at 
http://www.iana.org/assignments/ipv4-address-space).

In my opinion, 1.0.0.0/8 should not appear in any of the HIP internet drafts.
(So where do those of us who are experimenting learn of the current
 unnoffical parameters that we are using?  Perhaps a
'ietf-*-hip-temporary-pre-IANA-constants-for-testing-01.txt' draft
should be written and maintained.)

Here is my memory of how the HIP community arrived as using 1.0.0.0/8
in the interoperability tests we've been doing (unofficially-) at IETF
meetings for the past few years:

We originally wanted to use 127.0.0.0/8 or perhaps 127.128.0.0/9 for
LSI space but there were some problems where 127.0.0.0/8 was a bit too
hardwired into the linux (2.4.x) kernel, and we couldn't get away with
that.   (One of the furthest-along implementations was written
entirely in python, and had no other reason to patch the linux kernel.)

I suggested that we use 0.0.0.0/8 but there were also problems with
existing code that would not allow for a zero network value (and I
think there may be some APIs that would break).

So I took a look at the IANA IPv4 address space assignments
and suggested 1.0.0.0/8 be used.

But I say again, IANA has *not* made this assignment.  1.0.0.0/8 was
chosen for expediency when we were at IETF meetings and wanted to test
interoperability.

I believe 127.128.0.0/9 would be a much better choice, and much less
likely to raise objections.  But how much additional burden this would
place on implementors, I am not sure.

Yes, we would want a similar allocation for IPv6.  I figure an IPv6
/16 might be the appropriate size to ask for (why would anybody object
to that?), but perhaps we should do some analysis to make sure that
the remaining 112 bits are enough.

We should somehow seperate our need for "what we experiment with now"
values and final TBD official IANA values.
(A Protocol Number for HIP comes to mind.   Are their any others that
need to be assigned from existing registries?   Do any new IANA
registries need to be created for HIP?)

			-Tim Shepard
			 [email-masked]

---

From: [email-masked] (Miika Komu)
Date: Wed Mar 17 04:20:00 2004

On Wed, 17 Mar 2004, Stephen Sprunk wrote:

> this doesn't seem clear in the draft (to me).

It has been left out the draft to avoid bloating the drafts. The API
issues are being experimented as we speak and later written on a separate
draft.

The API is divided into two: legacy HIP API and the native HIP API. What
you described in the email was the legacy API, so let's focus the
discussion on that subject for now.

> Would these be the local and remote addresses of a socket returned by
> API calls?

Yes.

> If that's correct, presumably an LSI would be returned to IPv4-only API
> calls and an HIT would be returned to IPv6-aware calls.

Yes.

> Since HITs may collide with valid IPv6 addresses, would they have a
> different AF_* number?

As it is stated in the draft, the two uppermost bits in the address
indicate that the address is really a HIT. The bits have not been yet
assigned by IANA.

I guess most of the implementations still use AF_INET or AF_INET6 in the
socket addresses because otherwise one would have to implement a AF_HIP
socket handler in the kernel. However, in the native API, we are
experimenting with the introduction of AF_HIP (and some other things as
well).

> Is an HIT or LSI a valid source and/or destination address when creating
> a new socket?

Yes, if the system knows the mapping from the HIT/LSI to the corresponding
IP address(es).

> connection is completed (presumably as late as the R1+R2 timeouts).

The address changes are not reflected on the application socket address
data structure. What you really have there is a HIT, LSI or IP address.

If the socket address contains a HIT or an LSI, base exchange is tried
with the endpoint. If the base exchange fails, it is still possible to
fall back to plain TCP/IP if the localhost knows the mapping from the HIT
to IP address and the local HIP policy allows this kind of fallback.

If the socket address contains an IP address, it is still possible to use
opportunistic HIP. This requires that there is a local policy configured
to use HIP with the specified destination address. Again, there is a
possibility here to fallback to plain TCP/IP, if the base exchange fails
and the local policy allows such a fallback.

But in any case, the address changes are not reflected to the application.
This is especially true in the HIP legacy API.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

---

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

Thus spake "Miika Komu" <[email-masked]>
> issues are being experimented as we speak and later written on a separate

Fair enough.

> experimenting with the introduction of AF_HIP (and some other things as

I don't think it's reasonable to co-opt fully 1/2 of the total IPv6 address
space for HIP without involving IANA, and hoping they will never use any of
those addresses.  If HITs are going to be part of AF_INET6, then we need a
specific allocation (perhaps a /16) from IANA.  If they are not going to be
part of AF_INET6, we need a new AF_* number from IANA.  Ditto with co-opting
1/8 for LSIs.

> > This also makes me wonder how an application is expected to handle
> > the case where the local and/or remote "address" changes (to an LSI
> > or HIT) from what is specified before the connection is started,
possibly
> > even well after the connection is completed (presumably as late as the
> > R1+R2 timeouts).
>
> ...

Sorry, I meant that when an application uses the legacy API is used to
connect from IP1 to IP2, later API calls may reveal the actual connection is
between LSI1 and LSI2 or HIT1 and HIT2 instead of the specified IP
addresses.

I have a nagging feeling this can cause problems, but I can't put my finger
on when it would happen.

S

---

From: [email-masked] (Stephen Sprunk)
Date: Wed Mar 17 10:08:04 2004

Thus spake "Tim Shepard" <[email-masked]>
> should be written and maintained.)

AFAIK, standard practice is to state the final value is TBD and then give
the value used during development (in the main drafts).

> the remaining 112 bits are enough.

We've certainly wasted larger portions of the IPv6 address space on other
things, so it's not a big reach.  When we get closer to requesting an actual
allocation, we'll need to check not only the size required but if there are
specific ranges it should or shouldn't be allocated from.  Also, since there
are different forms of HITs (type 1, type 2, etc), we may need to specify if
each type gets its own allocation, or if all of them will be under a single
HIP allocation (and thus each getting fewer actual bits).

> registries need to be created for HIP?)

Off the top of my head, the draft expects IANA to manage HIP packet types
and TLV types, plus the assumed protocol number and IPv4/v6 allocations.
There might be more I'm forgetting.

S

---

From: [email-masked] (Tim Shepard)
Date: Wed Mar 17 14:23:00 2004

> HIP allocation (and thus each getting fewer actual bits).

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

I suggested that the type 2 HIT stuff be removed from the draft a year
or so ago (in conversation).

			-Tim Shepard
			 [email-masked]