Re: [Hipsec] Selection of LSI address block

["Henderson, Thomas R" <[e-mail]>]

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

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.

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

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.

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

Agreed, if we can obtain it.

Tom