Subject: Re: [Hipsec] Thinking about LSIs

From: Robert Moskowitz <[email-masked]>
Date: Thu, 4 Sep 2008 14:56:22 -0400

Tim Shepard wrote:
> The LSI hack (where HIP is imposed between an oblivious app and the
> network) is both appealing and appalling.
>
> Much of the negative reaction to HIP I've heard from people involves
> their concerns about the damage that will be done when/if HIP is
> "imposed" in this way.  I recall an IESG member explaining once that
> HIP would do more damage to the net than NAT.
>
>
> Of course the appeal is how HIP could be enabling in situations where
> things would otherwise not work.
>
> I think what is needed is a clear understanding of when it makes sense
> to impose HIP and when it does not.
>
>
> I am curious what IPv4 [-only] apps Bob is thinking about.  AFAIK all
> the important apps and servers on linux have been v6-capable for at
> least 5 years if not 10.

I thought that too, and have been totally dismayed to find out otherwise.

What do I use for remote console? VNC does not support IPv6, RealVNC 
seems to, but that costs $$. TightVNC was claimed to but does not. 
FreeNX? Well that is just using SSH, and well there is HIP, so why use 
SSH? Telnet over HIP looks to be fairly equivalent to SSH UserID mode (I 
have not really spent the time to really map these out.

VSftp works fine as a v6 ftp server. What is the client? gFTP is giving 
me a segmentation fault and no response to questions from the author 
(Maybe that is a Centos problem?).

Firefox 3 is locking up over the HIPL implementation. Might be something 
HIPL is doing to impose itself, or it might be Firefox 3 being too smart 
for itself. It works fine over v6 without HIP...

Of course things like rsync are 'normally' run over SSH. I am going to 
have to look at running the rsync daemon now and see how it fairs over v6.

Haven't looked at SAMBA yet. That is VERY low on my testing order.

Finally what started this all is SIP. What to use. Linphone is not 
available for i386 RHEL 5/Centos 5. Seems to be a library problem. But 
where are other v6 SIP phones? SIP Communicator has v6 on its 'roadmap'.

And then there is Asterisk. Ha! One developer is working on porting it 
to v6, and not getting much backup it seems from the Digium team to roll 
it into the tree.

So perhaps the main servers are there. But the clients are a problem.

> Of course there is a heavy tail of
> applications, many of which are probably still IPv4-only.  But I think
> it would help to explicitly mention the examples you are thinking of
> when talking about IPv4-only apps because they're not all going to be
> the same in how they need to be handled (whatever the trick may be
> that gets them capable of communicating over an IPv6-only network).
>
>
> Instead of "imposing" HIP between an oblivious app and the net in the
> stack, I think a better approach would be to do something similar to
> how SOCKS can be imposed between an oblivious app and the net by using
> the "socksify" program from the Dante implementation of SOCKS.    This
> way it is easy (at invocation time) to choose whether a particular
> program should or should not have something imposed between it and the
> net.
>   

My SOCKS experience is very old, and it was on Win2000 (back before my 
move to Linux). So far I have had to explicitly enable reaching a IPv4 
server by adding a resolvable LSI for the server (by putting 1.0.0.n 
into the /etc/hip/hosts file for now). When the IPv4 app does its DNS 
query, it has to get back an LSIish reponse that is mapped to the IPv6 
address of the server's HIT. I suspect there is a lot of difference 
between implementations on how this is handled.

> I imagine a program called "hipify" that works much like "socksify",
> but would (I think) be somewhat more complicated than socksify and
> may need to communicate with a daemon running on the local machine
> that is tracking things like DNS answers that have been spoofed into
> LSIs, etc...   Anyone else been thinking along these lines?
>   

Exactly what I am thinking. The DNS resolver gets a AAAA record and a 
HIT. Something then needs to impose and provide the app with a remote 
LSI for things to work. So perhaps there might be a app registration 
process into this hipify to limit where the magic is applied. But more 
likely once hipify is enabled, it would be enabled for MOST IPv4 apps.

> Like some applications are SOCKS aware (where you can do things like
> configure the SOCKS server to use in the apps native configuration
> screens), it will make sense to make some applications HIP aware
> (and precisely what that will mean I have not thought about much).
Ditto.

_______________________________________________
Hipsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/hipsec

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 4 Sep 2008 15:15:19 -0400

Missed one point.

> HIP would do more damage to the net than NAT.

Yet I see too much handwaving about IPv6 deployablity. It is part of the 
'force them to convert' mindset in my view. HIP enabled IPv4 apps would 
perpetuate IPv4 apps, just as NATs have perpetuated IPv4 itself. So stop 
this stuff and just get developers to get their stuff working on IPv6 
already.

I remember running 1401 emulation on our 370s as we no longer had the 
source code for those 1401 programs and we had a business to run. So IBM 
supplied us with the emulation tools. Ran that for years before all the 
apps were aged out. Oh, did I say years. We started it on 360s, and 
continued it on the 370s before we finished them off....

But I would like to know how HIP enabling IPv4 apps over IPv6 would be 
'more damaging' than NATs. Can youpoint me to the facts this person 
supplied?

> to impose HIP and when it does not.

Just like there is finally some analysis of types of NATs and what they 
mean to users and apps. Gee, sounds about right.

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 4 Sep 2008 13:34:36 -0700

> likely once hipify is enabled, it would be enabled for MOST IPv4 apps.

I think what is important to think about is what should be the user and
application experience, and how to deploy it and troubleshoot it, and
how to manage the policy.  Whether it is actually implemented as a
socksify approach or as some kind of DNS spoofing mainly should be a
question of how you want users/system administrators to deal with it.
The existing HIP software can functionally do "hipify" already.

I think that HIP is going to have similar issues with IPv6 applications,
by the way, and I wonder whether the IESG complaint will still apply.
Namely, IPv6 LSIs, and/or the need to substitute LSIs or HITs into the
resolution process.

Tom