[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Hipsec] Selection of LSI address block



Henderson, Thomas R wrote:

Hi,

-----Original Message-----
From: Miika Komu [mailto:miika.komu at hiit.fi] Sent: Thursday, August 20, 2009 2:35 PM
To: hip WG
Subject: Re: [Hipsec] Selection of LSI address block

Henderson, Thomas R wrote:

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

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.

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.

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.

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!

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

3) Management for LSIs without a fixed prefix would be more complicated for ACLs in legacy apps. It makes the administrators life more complicated.


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.

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

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.

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.