Subject: [Hipsec] Selection of LSI address block

From: Robert Moskowitz <[email-masked]>
Date: Wed, 19 Aug 2009 17:37:17 -0400

We need to come to a quick determination about what we use for LSIs.

I have been asked by IANA for clearification on what HIP has been using 
1.0.0.0/8 for.  I pointed them to the text from 4423 for now.    But 
note that Net1 has been released to the RIRs.  Here is what I have been 
told:

=============================================

Whichever block is selected for HIP LSIs we will need to follow the
direction in section 4.1 of RFC 2860:

   4.1. The IANA will assign and register Internet protocol parameters
   only as directed by the criteria and procedures specified in RFCs,
   including Proposed, Draft and full Internet Standards and Best
   Current Practice documents, and any other RFC that calls for IANA
   assignment. 

If the IESG are willing to direct us to reserve a particular /8 or (or a
part of it) for a special purpose then we would do so and make sure not to
allocate it to an RIR. However, for the time being, 1.0.0.0/8 is available
for allocation to RIRs and could be allocated.

=============================================

We have discussed using 127.0.0.0 for LSIs, say 127.100.0.0/16, but will 
that really work?

Will the kernels handle them in a reasonable way?

What will protocols like the FTP command channel's use of IPaddresses 
look like?

Or referalls?

Can anyone shed light on this or actually do some testing?

If we REALLY need routable addresses, we need a serious dialog with IANA 
now.

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Wed, 19 Aug 2009 15:24:37 -0700

> We have discussed using 127.0.0.0 for LSIs, say 

in the OpenHIP software we have a macro IN_LOOP() to check if an IPv4
address is equal to 
(INADDR_LOOPBACK >> IN_CLASSA_NSHIFT), i.e. if the top bits equal 127
(see /usr/include/netinet/in.h on Linux)

I wonder if other applications use similar techniques to check for
loopback addresses? Using 127.100.0.0/16 would be problematic in that
case.

-Jeff

---

From: Miika Komu <[email-masked]>
Date: Thu, 20 Aug 2009 09:45:37 +0300

Ahrenholz, Jeffrey M wrote:

Hi,

> loopback addresses? Using 127.100.0.0/16 would be problematic in that

many apps probably (?) just check 127.0.0.0/8 which could be a big 
problem for HIP. I would prefer getting a slot from 1.0.0.0/x address 
space to avoid such problems. We have been experimenting with the 
1.0.0.0/x address space without any problems.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 20 Aug 2009 06:28:39 -0400

Miika Komu wrote:
>>> We have discussed using 127.0.0.0 for LSIs, say 127.100.0.0/16, but 
>>> will that really work?
>>
>> address is equal to (INADDR_LOOPBACK >> IN_CLASSA_NSHIFT), i.e. if 
>> the top bits equal 127

Then we need to make an official request from IANA.

It should come from our chairs. But some text from our developers as to 
why 127 won't work MAY be of value.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 20 Aug 2009 11:13:31 -0400

Robert Moskowitz wrote:
> I have been asked by IANA for clearification on what HIP has been 
> using 1.0.0.0/8 for. I pointed them to the text from 4423 for now. But 

Further along this please read:

http://www.ietf.org/id/draft-iana-rfc3330bis-11.txt

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 20 Aug 2009 11:15:35 -0400

As our chair pointed out, we DO have to get recharted by the IESG to 
actually get the agreement by the IESG that we are moving HIP from 
experimental to standards track.

Anyone want to take a crack at the charter text? I hope our two chairs 
will agree to stay on for this next step.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 20 Aug 2009 13:49:11 -0700

> -----Original Message-----
> From: Robert Moskowitz [mailto:[email-masked]] 
> Sent: Thursday, August 20, 2009 3:29 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Hipsec] Selection of LSI address block
> 
> Miika Komu wrote:

For use within the host only, I think it would be nice to get an
allocation for this type of usage, but I don't think it is strictly
required.  It seems to me that the main requirement for LSIs is to use a
range of 32-bit numbers that can be distinguished from destination IP
addresses reachable from the host, but that are not in the range of
special IP addresses (224/8, 127/8) that might be checked by
applications.  The other consideration is that some other overlay on the
host is not using those same numbers (i.e. they need to be locally
deconflicted).  Use of private address space or just squatting on some
other prefix like within 240/8 should also work and be permitted in the
specifications (i.e. should be a matter of local deployments). 

For use within a larger scope, such as a site, an address range in an
existing private address block might be the best choice.

If there is a request for special allocation, it might help to note that
the need is more general than HIP and that other overlays could use
this; i.e. maybe something like an "HID" (host identifier) prefix for
IPv4, of which HIP is one use case.

Tom

---

From: Miika Komu <[email-masked]>
Date: Fri, 21 Aug 2009 00:34:46 +0300

Henderson, Thomas R wrote:

Hi,

> IPv4, of which HIP is one use case.

sorry, but I'd disagree on using private address realms for LSI. IMHO, 
the private address space is the worst choice for three reasons:

1) You have to guess which one private address space is unoccupied for NATs.
2) Mobility can cause more conflicts with the selection of the LSI 
prefix selection. Implementations would have to handle dynamic 
renumbering of the LSI prefix and it would be a mess!
3) Management for LSIs without a fixed prefix would be more complicated 
for ACLs in legacy apps. It makes the administrators life more complicated.

The 1.0.0.0 prefix is the least problematic and 127.0.0.0 is the second 
best, IMHO.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 20 Aug 2009 21:39:33 -0700

> From: Miika Komu [mailto:[email-masked]] 
> Sent: Thursday, August 20, 2009 2:35 PM
> To: hip WG

Yes, I agree that if all private addresses are in use in a site, or one
cannot determine which addresses are likely to be active, then private
space may not be a good choice.  However, many sites where HIP may be
deployed may not otherwise use private space at all.  Also, note that
some applications (e.g. virtual machine monitors) already scan networks
for unused private subnets and start using them once a vacant one is
found.

> renumbering of the LSI prefix and it would be a mess!

Yes, if you are roaming into unknown networks, this would be a bad
choice.

> for ACLs in legacy apps. It makes the administrators life 

What kind of ACLs in applications are you thinking of?

> The 1.0.0.0 prefix is the least problematic and 127.0.0.0 is 

I agree that if we can obtain a full /8 for LSIs or host identities,
that would be easiest.  I'm not sure 127/8 is preferable to private
space for the reasons Jeff mentioned, but it probably should be tested.
If we were to obtain a smaller prefix such as /16, it probably would
still be OK but would reduce the likelihood that LSIs could easily be
randomly generated (such as using the low order bits of the HIT) without
collisions.

I would be willing to amend my previous statement such as:

For use within a larger scope, such as a site, an address range in an
existing private address block might be the best choice, unless the
host may, in the future, move to or obtain an address on a network 
that uses such private addressing.

Anyway, it is not going to affect interoperability if an implementation
chooses an unused private address block, an unallocated block, or
something like Net1.

Tom

---

From: Miika Komu <[email-masked]>
Date: Fri, 21 Aug 2009 07:50:46 +0300

Hi,

> for unused private subnets and start using them once a vacant one is

there may be also some applications that don't scan networking and 
assume that all 192.168.0.0 and 10.0.0.0 networks are NATted. Such as 
p2p software.

> What kind of ACLs in applications are you thinking of?

The admin can allow only secure and/or authenticated communications with 
LSI-based ACLs in existing legacy applications. Either the whole LSI 
prefix or individual LSIs (that are locally statically mapped to HIs). 
Think about the ACLs in apache, sendmail or /etc/hosts.allow.

> chooses an unused private address block, an unallocated block, or

I think it would be better for usability of HIP if the "secure prefix" 
for LSIs would be always the same independently of the individual hosts. 
It's not really application layer issue, but rather human layer issue.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 20 Aug 2009 22:08:29 -0700

> assume that all 192.168.0.0 and 10.0.0.0 networks are NATted. Such as 

good point.  Although this would be akin to a case where both peers are
behind the same NAT, it may cause extra NAT traversal machinery to kick
in.

> Think about the ACLs in apache, sendmail or /etc/hosts.allow.

Yes, but I was thinking that whatever LSI prefix was selected, it has to
be put into such ACLs-- I'm not sure private addresses really changes
this much.

> It's not really application layer issue, but rather human layer issue.

Agreed, if we can obtain it.

Tom

---

From: Miika Komu <[email-masked]>
Date: Fri, 21 Aug 2009 08:18:14 +0300

Hi,

> behind the same NAT, it may cause extra NAT traversal machinery to kick

btw, I am not saying that this is the right way to implement 
applications. In fact, ICE has a completely different philosophy which 
is more obvious when you think about building a large, isolate "lab" 
network from the private address range. But some apps, nevertheless, are 
just doing this even though it's "wrong".